Re: Possible bug report: git checkout tag problem

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 8, 2018, 13:51 UTC
Message-ID: <nycvar.QRO.7.76.6.1801081447350.31@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <160d3e3f291.df909f06277296.7997490218741761365@myles.hk>

Hi Myles,

On Mon, 8 Jan 2018, Myles Fong wrote:

Show 9 quoted lines

> 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