Hacker News Reader

Comment by Skunkleton | Hacker News Reader

Lots of confused beginners in this thread. IMO diagrams, and tutorials, that take this approach to teaching git are the reason people have such a hard time. After learning the very basic commands, the next step is to learn the internal data structure of git at a conceptual level. This may seem like a bad design to some, and that is a reasonable thing to debate. It doesn’t change the reality that knowing basic git internals makes git much easier to use.

View on HN

I disagree that you need to know the internals. You need to understand an abstract model, that may have been influenced by internals of early versions, and part of such internals may have been preserved into current versions. But unless you want to modify git, you should not have to know anything about the internals. The abstract model is enough. I consider to know virtually nothing of git internals, yet I consider to be proficient in understanding its abstract model and using it.

Or so you may think. Working with diffs / merge conflicts already exposes you to internals. Knowing that committing big binary blobs is a bad idea also could be categorized as "knowing internals". Knowing why LF/CRLF leads to conflicts (without setting .gitattributes) also is knowing git internals.

It really doesn't, because you can know HEADs and the working index and the Merkle tree works, and even know the how you want the internal state to be transformed, but still run into "ok what is the command for doing what I want? Is it git-stamp-log or git-execute-detached-head?"

The approach I take when I'm not sure of which subcommand to use is to read through the git man page and skim through the commands listed. If one looks like a candidate, I'll open up the man page for that command and see if it's what I need.

Anyone who doesn't really understand what a graph is, and what a branch means in terms of graphs, has nothing to map those commands to. Sure, they form some internal model. Maybe "commit = save", "checkout = load", but load what? Oh, load that commit id, okay. But now they are at the "final v2 ZIP.ZIP" stage, not terrible, but they'll bleed out on the first git pull that results in a merge conflict :/

Speaking of merge, I'm a git user since ~2010, submodules, interactive rebase, filter-branch, sure, they are simple from a graph perspective, but I still don't fully understand how git knows which diffs to pull up during merge conflict... :D ... and now reading the answers here, it seems when it does the merge it uses the graph only to find the merge-base, and then it's just 3-way merge, which doesn't really map to individual commits. (And because the 3way diff looks at the raw text this means during the merge the branches are "squashed" into 1-1 commits both on top of the common base.)

Agree. Definitely think trying to learn the model first just results in confusion. First learn a few basic command so you can get by then delve deeper.

Reply on news.ycombinator.com