Comment by eyelidlessness | Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

Parent Full thread

> I don't understand any developer's that aren't willing to put in the time to learn how to use Git

I can effectively use, I don’t know, probably the about 5% of git that I need to do my job. It could maybe benefit me to learn 5% more? The rest feels like a trivia rabbit hole, I have shit to do, and I already have a lot of difficulty with cognitive load and far too many yaks to shave daily. With that said, I have no strong disagreement with you, but I do want to add a bit of nuance: “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start. Or continued learning has any practical benefit.

A little less nuanced: I encourage everyone who will listen, even experienced devs, to use a GUI frontend. Not just because GUIs do ~90% of what you’ll normally need in a daily workflow (which is especially good for noobs who learn which things are important to know first). Also because the GUIs generally have really obvious cues for how to unfuck a mistake, which is the most difficult thing for people who aren’t already well adjusted to git. I use a git GUI for almost all of my version control tasks, and I’m much more effective for it.

I’ve learned more how to use the git CLI for an art project than I’ve ever needed to know for normal work processes.

(Self nit: bullshit made up approximately educated guess percentages)

This (and the reply to js2) gives me the impression that "effectively use 5% of git" means something like "effectively use 5% of the git CLI surface", but to me that's not what "learn how to use git" means.

One way or another, I've wound up becoming the git guy at work, and think I'm on the more proficient side of average. But, for most anything outside of commands I use daily (or can easily find in shell history), I'm off to the git docs or a search engine. Just about always, I know what I need git to do, it's just a matter of finding an incantation to do it.

To me, there are two pieces to learning git. The lower level is about git itself: understanding that commits are snapshots and the diffs are calculated on-the-fly, that cherry-pick is an automated version of diff and patch, rebase is like a way to compose cherry-picks. The other layer is about how the organisation uses git - like how to fork a project on github, push some changes to a branch in your fork, make a PR to propose those changes to upstream, why committing directly to main is a bad idea.

> understanding that commits are snapshots and the diffs are calculated on-the-fly

I never understood why that gets mentioned as essential for understanding git. A version control system has to be able to produce both all versions of a given file and diffs between versions of a file, but how it does that is an implementation detail. There are many options there: full first version with diffs to newer versions, full last version with diffs to older versions, variants of those with full versions inserted every now and then, mixes of forward and backward diffs (as is done in some video formats, if you see each frame as a version of a file), etc.

Of course, there may be performance reasons for choosing an implementation. I could understand statements such as “Because of the existence of merge commits, it’s easier to store full files, rather than diffs, as a merge commit would have diffs with each of its parent that must be kept consistent”, but the “understanding that commits are snapshots” claim isn’t about implantation details, but claimed to be essential to understand git.

I think a key thing that may be trying to be communicated here is that in guy, commits are primitive, and not branches.

That's a good question, and I don't have a straightforward answer.

I think git sits in a sort of uncanny valley, where it's possible to go a long way treating the tool as a black box (and you're totally right - snapshots vs diffs is an implementation detail), but in practice, to really "get it" it's necessary to understand a bit about what is going on under the hood. The problem space that git addresses is inherently difficult, in contrast git internals are quite straightforward.

So, a person wanting to learn git has two options: they can keep the hood closed, study the manual, and fret over all the complicated looking knobs and switches. Or, they can have a look under the hood, realise that there really isn't much to it. Most of those controls just aren't relevant to do what they need to do at the moment, and when a problem arises they have a much better idea of where to look for solutions.

In my experience, being a well-rounded software engineer (for instance able to collaborate with a team at work, and make the occasional PR to random outside projects) requires a certain level of git proficiency. At that level of proficiency, the black-box approach seems to have a much steeper learning curve than the look-under-the-hood approach.

At a less philosophical level: git is a collaboration tool, and people get hopelessly confused about this stuff when they try to collaborate without sharing a common language. "How do I email a commit?" is the sort of question I get asked occasionally.

> “learn how to use git” is extraordinarily open-ended, and one of the most challenging parts is to know where to even start.

It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.

But under that atrocious CLI git is very elegant and simple conceptually. Once you understand the underlying concepts (blobs, trees, commits, refs, index/stage) the rest flows naturally.

Now I've been working with it since its earliest days including contributing to it here and there, but I never really found it very hard to grok.

"Git from the bottom up" is dated but git hasn't changed conceptually since then. "Git for computer scientists" is another good one. But any of the tutorials that start with git's low-level concepts and build from there are where I'd start.

> It's not really. It seems like it is because it has a baroque CLI with a ton of commands and those commands all have a ton of switches and the same commands can do lots of different things.

This quote-only reply was meant with kindness, but you made my point far better than I could have made it myself.

Do you want to be right or do you want to win? I was trying to remain sympathetic to your concerns while offering an alternate approach to learning git you might not have considered. I don’t have any trouble with git’s CLI but I understand why people find it frustrating. That is all.

> Do you want to be right or do you want to win?

Neither! I appreciate your perspective, and wish I’d emphasized that more than I did.

I’ve yet to meet anyone using git command line in their day to day activity. Everyone’s just using IDE. So IMO git CLI is not the issue in most scenarios. You might want to have git guru in your team to resolve some particularly hard situations, but that should be an exceptional situation.

Inversely, I don't think there's a single developer in my work center that routinely uses git anywhere but the CLI. I think CLI git usage may be more common than you believe.

Reply on news.ycombinator.com