It seems odd to me this behavior, I have a git tag, lets say tag-a, when I checked it out by running the following:

git checkout tag-a

it checks out tag-b

user@server xxx ~/path/git-local-folder ((tag-b))

I would guess there is some sort of relationship between tag-a and tag-b but I don't know what it is and the logic of it

CodePudding user response：

The "git checkout" command has several modes of operation, which it selects automatically based on the kind of argument you give it. The ones relevant right now are:

• If you give it a branch name, it updates the working tree and staging area to the current commit referenced by that branch, and updates the HEAD marker to the name of that branch. Subsequent operations, such as "git commit" then know to move that branch pointer.
• If you give it a reference to a commit other than a branch name, it updates the working tree and staging area in the same way, but doesn't record any branch name as HEAD. This is referred to as a "detached HEAD", and a subsequent "git commit" won't move any branch pointer. A tag name falls into this category.

Note that the newer "git switch" command forces you to make this distinction explicitly: if the argument is not a branch name, it will fail unless you specify the --detach option.

Now, when your prompt tries to display the currently checked out branch, the simplest place to look is in the HEAD file. But if you are in a "detached HEAD" state, that will just contain a commit hash, regardless of how you chose that commit. So the display code has to pick something to show instead of the branch name. It can look if there are any tags pointing at the currently checked out commit, but if there is more than one tag pointing at it, it doesn't know which one you used, and just has to guess.

In your case, "tag-a" and "tag-b" presumably reference the same commit. So once you check out that commit, the prompt you're using looks for a tag, and finds "tag-b", even when what you actually typed was "tag-a", or even the commit hash.