Subject: Re: [BUG]: git checkout on a new tag with current HEAD shows "head detached" at previous tag

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Tue, 05 Feb 2019 16:16:24 +0100

On Tue, Feb 05 2019, Dani Koretsky wrote:

> I have 2 tags such as release-17.6.230 and release-17.6.220:
> If I'm changing commits, all works as expected.
>
> If however both are pointing to the same commit, the output is as follows:
>
> git checkout release-17.6.220
> git status
> HEAD detached at release-17.6.220
>
> now if I run:
> git checkout release-17.6.230
> git status
> HEAD detached at release-17.6.220
>
> Which is theoretically correct, but I'd expect after checking out a
> certain tag I'd be see that specific tag...
>
> Sorry if this is intended behavior, I couldn't find clear mention of
> this behavior on the git checkout documentation online..
>
> Let me know if I can help in anyway.

You're right about this issue. I haven't dug deep into this, but just
enough to see why this is. When we "git checkout" something we write to
the reflog that we moved to such-and-such a ref, we then consult the
reflog when you run "git status" to see what we detached the HEAD from.

As you can see if you run "git reflog" after you check out the first and
second tag, that entry doesn't change, and we still note just the first
tag you checked out.

This is going to be because of a short-circuit behavior where we see "oh
we already checked this out".

Maybe that needs to be fixed as a bug, but would have more implications,
i.e. are there cases where you can flip-flop and end up spamming the
reflog, should the post-checkout hook run or not in those cases, etc.