If HEAD points to a branch, then `cat .git/HEAD` returns (at least on my Git version):
ref: refs/heads/2.x
So, to understand which branch HEAD points to, I can:
- Read file contents of `.git/HEAD`.
- Try to match the contents with the regular expression `^ref: refs\/heads\/(.*)$`. If the capturing group is not empty, then HEAD points to the branch indicated by the capturing group. Otherwise, HEAD does not point to a branch.
To do this using only plumbing commands, I came up with:
- Run `git show-ref --head --heads`.
- Parse the output first by newlines, then by spaces and test if the commit hash of HEAD is present in other lines. If it is, then extract the branch name and return it. If not, return empty string.
My question is, is there a "better" (more idiomatic, less "expensive", etc.) way of doing it using only one plumbing command? This solution is OK but it is more work than just matching one line with a regular expression. The reason I want to do this using only plumbing commands is because I think that plumbing command interface would be more stable than the format (organization, structure) of files under the `.git/` directory across Git versions. Please correct me if I'm wrong in this idea as well.
On Tue, Jan 05 2021, Utku wrote:
If HEAD points to a branch, then `cat .git/HEAD` returns (at least on my Git version):
ref: refs/heads/2.x
So, to understand which branch HEAD points to, I can:
- Read file contents of `.git/HEAD`.
- Try to match the contents with the regular expression `^ref: refs\/heads\/(.*)$`. If the capturing group is not empty, then HEAD points to the branch indicated by the capturing group. Otherwise, HEAD does not point to a branch.
To do this using only plumbing commands, I came up with:
- Run `git show-ref --head --heads`.
- Parse the output first by newlines, then by spaces and test if the commit hash of HEAD is present in other lines. If it is, then extract the branch name and return it. If not, return empty string.
My question is, is there a "better" (more idiomatic, less "expensive", etc.) way of doing it using only one plumbing command? This solution is OK but it is more work than just matching one line with a regular expression. The reason I want to do this using only plumbing commands is because I think that plumbing command interface would be more stable than the format (organization, structure) of files under the `.git/` directory across Git versions. Please correct me if I'm wrong in this idea as well.
You'll want to use git-rev-parse for this, e.g.:
$ git rev-parse --symbolic-full-name HEAD
refs/heads/master
On Tue, Jan 05, 2021 at 04:24:56PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
My question is, is there a "better" (more idiomatic, less
"expensive", etc.) way of doing it using only one plumbing command?
This solution is OK but it is more work than just matching one line
with a regular expression. The reason I want to do this using only
plumbing commands is because I think that plumbing command interface
would be more stable than the format (organization, structure) of
files under the `.git/` directory across Git versions. Please
correct me if I'm wrong in this idea as well.
You'll want to use git-rev-parse for this, e.g.:
$ git rev-parse --symbolic-full-name HEAD
refs/heads/master
Another option is:
git symbolic-ref HEAD
which has the benefit of working even when HEAD points to an unborn
branch. It also has a --short option to drop the refs/heads/ part.
It's also worth noting what you'd see on a detached HEAD. With rev-parse
you'll see "HEAD", but symbolic-ref will exit with a non-zero code.
-Peff