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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Feb 05 2019, Ævar Arnfjörð Bjarmason wrote:

> 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.

To add to this: I think there's a good case to be made that this is
definitely *not* a bug, and changing it would be introducing a bug.

It's 100% true that the "HEAD was detached at" the first first tag to be
checked out, the subsequent "git checkout [other tag]" was a noop.