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.
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.