Hacker News Reader

I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction.

> Perhaps others don't conceive of Git as a datastructure

The problem is that git doesn't really look much like a datastructure at first glance; it's ostensibly a shell command that you invoke, which makes people look at it in terms of inputs and outputs rather than spending time learning the details of all of the parts that aren't obviously in plain sight.

> A branch is a reference is a pointer to the latest commit in a series. Creating a new commit adds to the top and updates the pointer.

I think this is a pretty good demonstration of the issue I'm talking about; I've talked to engineers who totally understand git's underlying model but still are incredibly resistant to this definition of a branch, even though it's the accurate one. The idea of a branch conceptually being the entire chain of commits from the most recent one to the initial one is so pervasive that even the term "branch" heavily implies it (when arguably the more accurate analogy would be to call them "leaves"). When the definition of one of the most fundamental concepts defies people's common intuition, the finer details of advanced operations on them like rebasing don't have a chance of being widely understood. Git's failing isn't that it's complex, it's that the only effective logical unit to think about the system is the entire thing, and that lack of abstraction is the alien model to the way we're encouraged to think of things as programmers.

I've shown coworkers "git log --graph --oneline --decorate --all -50" many times and always have them start with it (and even use it throughout stepping them through something) to try and show that structure as we go. I think it helps a bit, but their IDEs go to great lengths to keep them out of the command line, so they're never completely sure what happened when it does something odd to their repo.

idk I clicked something and then there was an error so I deleted the project and started over

> but their IDEs go to great lengths to keep them out of the command line

Their IDEs can show them the graph you're talking about in a much richer form, lets them navigate through it, check what each commit did, who did it, and even change the graph (as everything in Git is changeable) by removing/rephrasing commits for example. I don't see how using the terminal actually helps anyone understand git, quite the opposite.

From what I've seen, they don't have that functionality. But my favorite is that it has a "sync" button for when a local and remote branch diverge due to a rebase, that doesn't tell you what it's going to do. The one time I saw it in use, it rebased new commits from master onto their branch.

IntelliJ: https://www.jetbrains.com/help/idea/investigate-changes.html

VSCode:

https://marketplace.visualstudio.com/items?itemName=mhutchie...

or https://github.com/gitkraken/vscode-gitlens#commit-graph-

SourceTree: https://confluence.atlassian.com/sourcetreekb/viewing-log-hi...

I actually understood Git much better as soon as I switched from a graphical interface (which was Git Tower at the time) to just using the Git CLI. I feel like the graphical interface/overhead obscured what was really going on and made me not so much learn Git, but the tool on top of it.

Git Tower is actually a great tool, but I believe Gits core concepts cannot be understood well without lots of experiments with the bare Git CLI (what helped me most was making toy repos → testing my hypotheses on how things work → observing/inspecting results).

> arguably the more accurate analogy would be to call them "leaves"

I don't think so. Branches are the more accurate analogy because two branches can have many commits on top of each of their common, parent commit - so branches grow as tree branches do, not leaves.

> so branches grow as tree branches do, not leaves

That’s exactly the mistake though - branches (the implementation detail) don’t grow. Branches - under the hood - are “one pointer to one commit”, and they are always the same size.

The suggestion to call the implementation “leaves” is because you get a pointer to one commit at the end of the branch, and you can then follow that branch backwards (via the linked-list of parent-commits) until you reach the trunk. But the “branch” is never actually stored anywhere, it is only implied by its ends.

That makes no sense. Different branches always have a common parent commit which is the "branching point". When you update the branch to point to a new commit, your branch is growing apart from the other. The branch analogy makes much more sense.

> I think the disconnect is that the "first principles" that you can derive from are implementation details; in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction.

Of the things mentioned in that comment, only SHA1 is really an implementation detail. The rest, especially how commits and branches relate to each other, is basically the core model of using git. The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design).

(To give an idea, I'd condense SVN's model down to similar terms: commits are a snapshot of the repository given a revision number, and branches are copies of the folder structure, or parts thereof, conventionally under branch/)

> The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design).

A lot of VCS have used diffs to implement commits. But... they have also used snapshots from time to (every N commits) in order to make checking out old commits more efficient. Apparently this is how Mercurial works and how either Subversion or CVS implements it.

This is based on some article I read yesterday. I could dig it up if this turns out to be wrong.

Now that is an implementation detail: all of those tools treat commits as snapshots primarily. Internally they may use diffs in order to compress the data (as does git), but the commits are primarily presented to the user as snapshots, and only secondarily treated as diffs in some circumstances (this flipping is a confusing point, to be fair, and something which git does a lot more of, which I think can add to the confusion. e.g. rebases are really turnings a series of commits into diffs, and then applying those diffs onto a different base commit to create a new string of commits. But the git man page just describes this as 'moving commits'. SVN and CVS just don't support this functionality, and mecurial buries it behind an extension).

If you want examples of VCS that treat commits as diffs conceptually, look at darcs and pijul.

Good point about patch-based VCSs. The diff/snapshot thing is definitely an implementation detail for snapshot-based VCS. (I haven't tried out patch-based ones yet.)

> in other words, git makes the most sense if you embrace the inherent leakiness of the abstraction.

What about it leaks? I think this term is overrated. https://news.ycombinator.com/item?id=37752291

> The problem is that git doesn't really look much like a datastructure at first glance

All VCS have a data structure. It's inherent.

> All VCS have a data structure. It's inherent.

"having a data structure" is very different than "being a unique data structure that you won't encounter anywhere else". I don't think most programmers have implemented their own version control systems, so the idea that needing to learn a new data structure to learn git isn't obvious even if you consider it "inherent"

I was replying to a comment about how the fact that Git has a datastructure (or whatever was meant) is surprising since it's just a command that you call, which is absurd considering what it does (store revision history).

I tend to agree, however it took learning about git internals to get to this point. Most developers don't read stuff like that. Also git creators made the mistake of using terms like add and checkout to mean completely different things to older version control systems. I think that's where a lot of the confusion stems from.

Yes personally I also can't co relate with git being hard, I mean yes during the initial days of learning you get stuck, but it is the same with everything right ?

Git is a tree and the nodes are commits. All of the git operations are operations on the tree except for the staging which is a special place to put things before you make a node out of it.

Edit: it’s not a tree it’s a directed graph. But I find tree a very simple approximation that most people without a computer science degree can understand.

A Git repo is a DAG of commits, and each commit is a snapshot of your files, along with some metadata. Commits are immutable and point to their own parents. Branches and tags are pointers or labels on commits. Everything follows from that.

For me the parts that break my mental model are stuff like trying to check out an historical revision and ending up with a scary warning about a detached HEAD (wtf), or not being able to easily start a new branch from an older commit (like you could very easily in mercurial).

> detached HEAD

Believe it or not this actually fits into the model, albeit with a little more complexity.

HEAD is a special label that can point to other labels, specifically to "heads" which are the labels that represent branch tips.

Normally when you make a new commit, the current pointed-to branch head advances forward to point to the new commit, and the HEAD pointer follows that branch head pointer.

"Detached HEAD" is whenever HEAD points directly to a commit rather than a branch head.

When making new commits in this state, there's no branch head to advance, so HEAD itself will advance to the newly-created commit. However this is a little dangerous because once you switch HEAD to something else, commits in the DAG without a branch head at the tip/leaf would be considered "unreachable" and would be invisible in logs, and eventually will be deleted by the garbage collection process.

It's still ultimately all about operations on the commit DAG and labels/pointers therein, which to me is really elegant.

What is not necessarily clear from that mental model is what any given operation will actually do to the files in your repo (called the "work tree"). But Git is very consistent here and usually tries to keep the work tree in sync with whatever is ultimately pointed to by HEAD, unless you specifically ask it not to (as with `reset --soft`).

> not being able to easily start a new branch from an older commit

Unfortunately this is a case of CLI docs obfuscation:

  git branch new-branch old-commit

They should have just called detached HEAD for branchless mode. That's all that it is: HEAD is directly on a commit instead of pointing to a branch. Clearer and less caps lock.

But people also complain about the “branch” term so maybe they would like the more internal “head” term? In which case we're back to square one.

I suspect that the name "detached HEAD" is just a pun. Cute if you already know what all this stuff means, confusing otherwise.

Inside joke for a handful of people which confuses thousands of people would truly be in the tradition of open source.

I think I found it extra confusing because this action (check out previous commit, do some work, merge with main) was completely supported in my previous dvcs of choice, Mercurial.

The Git idiom in general is to make a branch for any work you intend to keep.

But I'm also curious what you mean by doing work on a previous commit and then merging with main. Maybe it's a way to solve a problem I hadn't considered before.

Been a long time since I used Hg, and I've mostly trained myself out of these ideas, but I'll try to recall the use cases.

1. Consider doing a bisect to find when a bug was introduced (which may now be in multiple branches) and being able to fix it immediately then merge and/or rebase over the current versions.

2. Working on a branch, you realize that you'd like to try an alternative approach to a problem. You check out a previous commit, leaving the branch in its non-working state, and try your alternative approach. If it works, you keep going on this version, otherwise you can just switch back. The temporary unnamed branch continues to exist until you choose to delete it (ideally before pushing!) . This unlocks a much lower inertia way to do small experimental work without having to formally label new branches, which carries enough weight to make me hesitate. I would do this all the time in Hg and almost never in git. In git I would probably reach for stash to achieve something similar.