[Please make sure to bottom-post or reply-inline on the git-ml.] Stijn De Ruyck venit, vidit, dixit 07.10.2015 11:57: > Yes it is the tip. > So all I'm doing is checking out the exact same commit (the tip of a branch), but in different ways and in different sequences. The result on disk is the same, but the issue is git branch/status doesn't always reflect what I just did... > > If I do git checkout origin/develop, git branch might still say "detached at 545a36f", which, while true, feels wrong. How can I know afterwards what branch I actually tried to check out? "Detached at origin/develop" would make that clear. > (I use this information in a build script to embed version information (including the branch being built) into the binary.) Well, you think you do, but you don't. That is: You're not 'moving'; the value of HEAD stays the same, and if you check the reflog, you see that the second "checkout" (which in fact is a no-op) is not recorded in the reflog at all - because the HEAD ref doesn't change at all, and the HEAD reflog is all about changes to the HEAD ref. In that sense everything is perfectly correct, in the same way as a fast forward merge is not "recorded" as a merge. The way you think about the checkout may change, of course. I'm not sure whether "no-op" entries in the reflog would do any harm or whether we should create them. (And I'm not sure whether the HEAD reflog is the right tool for your purpose.) Michael > > -----Original Message----- > From: Michael J Gruber [mailto:git@xxxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, October 07, 2015 11:07 AM > To: Stijn De Ruyck; git@xxxxxxxxxxxxxxx > Subject: Re: Branch information (git branch/status) inconsistent when in detached HEAD state > > Stijn De Ruyck venit, vidit, dixit 06.10.2015 15:03: >> Hello, >> >> Consider a repository with a develop branch tracking origin/develop and where HEAD = 545a36f = develop = origin/develop. >> Tested with Git 2.4.3 and 1.8.3.4 on Linux. >> >> 1) git checkout develop >> 2) git branch | head -1 (or git status) >> * develop >> 3) git checkout origin/develop >> Note: checking out 'origin/develop'. >> You are in 'detached HEAD' state. >> 4) git branch | head -1 >> * (HEAD detached at origin/develop) >> 5) git checkout 545a36f >> 6) git branch | head -1 >> * (HEAD detached at origin/develop) >> 7) git checkout develop >> 8) git branch | head -1 (or git status) >> * develop >> 9) git checkout 545a36f >> Note: checking out '545a36f'. >> You are in 'detached HEAD' state. >> 10) git branch | head -1 (or git status) >> * (HEAD detached at 545a36f) >> 11) git checkout origin/develop >> 12) git branch | head -1 (or git status) >> * (HEAD detached at 545a36f) >> >> As you can see, checking out a revision by SHA1 after checking out a local branch tells you you are detached at that SHA1. Ok. >> But, checking out a revision by SHA1 after checking out a remote tracking branch tells you you are detached at that remote tracking branch. >> And checking out a remote tracking branch after checking out a revision by SHA1 tells you you are detached at that SHA1. >> >> This is confusing. Is this by design? >> For a script I am writing, it would be great if the output would be consistent. Checkout origin/develop should always say "detached at origin/develop". Checkout 545a36f should always say "detached at 545a36f". >> >> It looks like the detached head information is only updated when a detached head state is entered and not anymore when a checkout occurs "within" a detached head state. >> >> Best regards, > > Does 545a36f happen to be the tip (value) of origin/develop? > > For a sha1 different from the tip, I can't reproduce the effect that you describe. There have been some changes in related code recently, but I don't think they should affect this scenario. > > Michael > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html