Why doesn’t a git tag show up on any branch?

Question

I cloned the mosquitto repo that has tag v1.4.9. However the tagged commit does not appear to be on a branch.

How could that happen? Does the author actually keep a branch on his own repo but only push tags from that branch to GitHub? Or does he just make a commit to a tag?

I made the tag into a local branch

$ git checkout -b work149 v1.4.9

and looked at the last commit on the branch:

$ git log -1
commit 91bfd82491f90e24b6fe9c036f0b04a1f5c14a89
Merge: bf959ef 2d0af73
Author: Roger A. Light <[email protected]>
Date:   Thu Jun 2 22:05:34 2016 +0100

    Merge branch 'fixes'

This commit is one ahead of the fixes branch.

With git log --graph I can see an earlier commit on the same branch (not the fixes branch, but a branch I'm trying to understand):

* |   commit bf959ef9b0ae0e4d74bf80158ffb0b7c69da533d
|\ \  Merge: 646e0a0 5cca6b4
| |/  Author: Roger A. Light <[email protected]>
| |   Date:   Sun Feb 14 14:38:42 2016 +0000
| |
| |       Merge branch 'fixes'
| |

How do you find out whether a tag is on a branch and on which branch? Does the leftmost vertical bar indicate a branch and where is that branch on the remote?

Is this a common practice?

The discussion thread “Git pull doesn’t get the tags” mentions “branch heads that are being tracked” and “non-commits.” I wonder whether the git clone command configures the clone not to track all the branches on the remote or the repo has somehow made the tags into non-commits?

Answer 1

My guess is the author probably had a branch that contained 91bfd82491f, tagged that commit, pushed the tag, and then later deleted the branch. You are also correct that the author may have a local branch that points to the same commit but pushed the tag only, not the branch.

Check which branch or branches contain v1.4.9 using

git branch -a --contains v1.4.9

Running that command gives no output, which confirms that it is not on a branch of its own. In contrast, look for v1.4.8:

$ git branch -a --contains v1.4.8
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/debian
  remotes/origin/master

One way to directly create a tagged commit outside any branch is to operate with a detached HEAD, that is where HEAD does not refer to a named branch. In the mosquitto clone, you can get there by running

git checkout v1.4.9

which gives you a chatty warning.

Note: checking out 'v1.4.9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 91bfd82... Merge branch 'fixes'

At this point, git will create more commits. For example:

$ touch look-ma-no-branch ; git add look-ma-no-branch

$ git commit -m 'Look, Ma! No branch!'
[detached HEAD 51a0ac2] Look, Ma! No branch!
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 look-ma-no-branch

This new commit 51a0ac2 does not exist on any branch, which we can confirm.

$ git branch -a --contains 51a0ac2
* (HEAD detached from v1.4.9)

For fun, let’s tag it too.

git tag -a -m 'Tag branchless commit' v1.4.9.1

Switching back to the master branch with git checkout master, we can use git lola (an alias for git log --graph --decorate --pretty=oneline --abbrev-commit --all) to see that the new tag looks similar to its progenitor.

$ git lola
* 51a0ac2 (tag: v1.4.9.1) Look, Ma! No branch!
*   91bfd82 (tag: v1.4.9) Merge branch 'fixes'
|\
| | * 1cd4092 (origin/fixes) [184] Don't attempt to install docs when WITH_DOCS=no.
| | * 63416e6 ;
| | * 5d96c3d [186] Fix TLS operation with websockets listeners and libwebsockts 2.x.
| |/
| * 2d0af73 Bump version number.
| | *   8ee1ad8 (origin/coverity-fixes) Merge branch 'fixes' into coverity-fixes
[...]

Confirm that it exists on no branch using

git branch -a --contains v1.4.9.1

Because you asked, no, this is not at all a common git workflow.