The "Current Branch" in Git | Hacker News Reader

The "Current Branch" in Git

jvns.ca

29 pointsingve10 comments

You're either in a detached HEAD state or you're not. Detached means HEAD points to a commit, otherwise it points to a branch. "Current branch" only makes sense when HEAD points to a branch. Otherwise, there is no "current branch".

HEAD is always a reference to the checked out commit. A "branch" is a named reference to a commit to a commit that will auto advance if you check it out and make new commits. A tag is a named reference to a commit that will not auto advance if you check it out and make new commits.

If you checkout a commit using something other than a branch name, new commits that you make will not auto advance any branches. This is what a "detached HEAD" is, since your HEAD is detached from any branch.

You're speaking at one level of abstraction up from the post you're replying to. You're both correct. It's just that you need to use the parent's level of abstraction if you want to strictly define "current branch".

One of the difficult things with git is it's hard to know which level of abstraction people are talking about. As I was typing my first comment I thought "well I guess a detached HEAD state is a branch too, as a branch is just a chain of commits". But that's at a completely different level of abstraction to where the OP is at. I would be at the "git as just a big ol' DAG" level but the OP is at the "git as a version control system" level.

I forgot that HEAD doesn't point to tags! I guess it makes some semantic sense - tags are just labels, and shouldn't "carry" anything with them if they move.

Great writeup. Technically "current branch" is easily defined: It's the branch (not commit or tag) HEAD points to, if any. "The last thing I checked out" is really just the last identifier you passed to 'git checkout', not what that resolved to and actually got checked out, or any commit-ish that HEAD has been pointed to in the meantime by other commands. "What's shown on my git prompt" could be any silly thing, since that's not git. However, colloquially (and even sometimes in the Git documentation itself!), "current branch" can mean other things, as the author enumerates, and it would be unrealistic to ignore that.

One note: It's silly that git prompts seem to choose an arbitrary tag to show when there's multiple - they should show all of them or none of them. However, the author says that 'git status' does the same thing, but for me (git 2.44.0), it does not report any tags, which makes sense to me (reporting all tags along with the SHA would also make sense).

To me the "current branch" means, if I make a commit, what will be updated to point at the new commit.

This is a much better post than the one that preceded it. Still...

The biggest problem with people's attempts to wrap their heads around Git, its awful UI notwithstanding, seems to be an insistence on thinking of it foremost in terms of the experience of running any given command. I.e., trying to understand it from the outside in. Indeed, it's awful UI certainly hurts the process.

Git's the stupid content tracker. Take a work consisting of a bunch of files, snapshot them, then create a new work (consisting of a lot of similar files, to be sure, but where others differ in some way). Git concerns itself with both of these collections as collections. It's true that it's got all this "branching" imagery, but that's an attempt to describe the relationships between the collections from the metadata attached to each one (collection 0ffcd473 calls collection f7d0c770 its parent). The branches are synthetic, imaginary. Not a lot different from a family tree or the "branches" you would get if you started mapping out the provenance of religious texts copied from another but each with their own copying errors (or deliberately editorialized content). The branches aren't really there—they exist as an aide for the researcher. The only real difference is that Git actually has explicit metadata, but still, the branches aren't there.

Focusing on Git's on-disk representation or other internals misses the point. The main thing is getting the files in the collection you're putting together right now to look the way you intend right now. Everything else is recordkeeping. (At least it should be—anything (whether it be a given tool, workflow, etc) that depends on it being any more complicated than this is fundamentally broken.) Git's whole deal was about being an alternative to manually futzing around with tarballs and/or multiple directories of source code sitting next to each other on your disk. (It's still that, but with a somewhat involved—but not very interesting—deduplication scheme in userspace. The other details are even less interesting than that.)

IMO the best way to think about git is at a happy medium level of abstraction (which most people tend toward anyways, it seems), where a commit is a snapshot, but can be thought of as the diff from its parent to it; a repo is a tree of commits over time (where lines can merge, so it's technically a graph, rather than a tree); a branch is a series of commits represented by a pointer pointing to the last commit in the branch, and you can think of that series of commits as either going back all the way to the initial commit or just back to another branch from which it diverges, depending on what you're doing with it. Etc. And then the commands operate on those things to achieve the logical goal of the command.

Re: Bad UI, I vacillate, but I don't disagree. I do think it needs to be said that people talk about git's internals not necessarily because the UI is bad, but also because git is so relatively clean and simple that you can talk about the internals. Conversations about other tools look simpler because most people can not reasonably talk about their internals in a casual format.

So, in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can, talking only about the UI and the results of using the UI, living with a limited, abstract understanding. Git enables them to understand better, with some effort.

> in a weird way, conversations about git are complicated because, unlike with so much other software, people don't just throw up their hands and get along the best they can

Sorry, I don't think that's compatible with reality at all. Too much experience with people clearly doing exactly that—frustrated people giving up, most often xkcd-style reset to the beginning—says otherwise. (And it's not just a matter of them existing. I'd wager this set probably accounts for the majority.)

People of course give up on trying to grok complex programs like version control all the time, git included. (where "giving up" means just using the UI and trying to derive meaning from the results with the minimal goal of achieving one task at a time). But in my experience, fewer people give up on understanding git internals than comparably complex program internals. I.e. the second layer of understanding is more accessible in git than in other software, where people often don't even start trying to understand the second layer, much less make real progress with that understanding.

Edit: Sorry if I am talking past any of your points - I'm not familiar with the XKCD comic you referenced.

Reply on news.ycombinator.com