Why doesn’t a git tag show up on any branch?
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
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
$ 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' v220.127.116.11
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: v18.104.22.168) Look, Ma! No branch! * 91bfd82 (tag: v1.4.9) Merge branch 'fixes' |\ | | * 1cd4092 (origin/fixes)  Don't attempt to install docs when WITH_DOCS=no. | | * 63416e6 ; | | * 5d96c3d  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 v22.214.171.124
Because you asked, no, this is not at all a common git workflow.
I did something similar by mistake: I was about to push a new release, I committed everything on my PC and added a tag.
Then I did
git push --tags, thinking erroneously that it would push the master branch and the tag. Then I created a release on github. The release was pointing to the last changes, but the master branch was behind. I had to push again, and that aligned everything.
The notable thing is that all the files were actually pushed with the first command (I saw it from the output, you know: creating deltas, etc). In the second push the transferred bytes reported 0, so I guess only branch metadata were pushed.