Hi Myles, On Mon, 8 Jan 2018, Myles Fong wrote: > Brief description: > When two tags are pointing to the same commit, e.g. tagA and tagB, if I > do `git checkout tagA` then `git checkout tagB`, and then `git status`, > it shows `HEAD detached at tagA` > > Expected behaviour: > I'm expecting it to show `HEAD detached at tagB`, though I understand > this makes no difference for the repo code, but still a bit confusing > for me. The problem here is that Git understands something different from what you intended: if you say `git checkout <commit-ish>`, Git is mostly interested in the revision, i.e. the commit. Only if that parameter refers to a local branch name (which is the only type of ref Git expects to advance via the worktree) does it switch to a named branch. Otherwise it switches to what I like to call "unnamed branch" (and which for historical reasons is called "detached HEAD" by Git, something that is unlikely to be understood without explicit explanation). Now, as a convenience, Git tries to name the revision when it is on such an unnamed branch. If a tag points to it, it uses the name of that tag to describe it. If *multiple* tags point to it, it uses the newest one. That's why you see what you see. It is intended behavior... Ciao, Johannes
