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.
