Some Miscellaneous Git Facts

jvns.ca

52 points·qsantos··4 comments

> not all references are branches or tags

Some more examples are `refs/pull/123/head` and `refs/pull/123/merge` on repositories hosted by GitHub. For a given pull request, these contain the most recent commit in the PR and the result of merging that PR into its base branch, respectively. You can see these with `git ls-remote origin`, and access them with (e.g.) `git fetch origin refs/pull/123/merge && git checkout FETCH_HEAD`. This can be really useful when reviewing a PR to test some things locally on the copy as it will be merged.

Another set is `refs/bisect/*`. In particular, after a successful bisect, `refs/bisect/bad` is the first bad commit.

Those are basically all the ones that I routinely use, in addition to those that Julia mentioned. `git filter-branch` populates `refs/original/**` (see its manual page for details), but that's a lot more niche.

The index and the staging area are not the same thing. If you define staging area as what will be committed, then the staging area is only one part of the index. The index also records untracked files and conflicts for example.

https://git-scm.com/docs/index-format

I've always understood the index as being the staging area and then you stage things in that staging area. Then those things become staged (also known as cached) in the index. I'll admit I've never quite understood why "cached" and "staged" are used interchangeably (or at least it seems that way).

staging or index is one of the most beloved by me features of git. It saved my careless butt from loosing files SO many times. I stopped counting. Severely underrated, even complained about to be confusing.

Reply on news.ycombinator.com