7

I know that, in Git parlance, "detached HEAD" corresponds to a state in which the symbolic reference HEAD is not pointing to any branch. I also know that git branch, for instance, will tell me whether I'm in detached-HEAD state, e.g.

* (detached from 9a2ef02)
  master

or not, e.g.

* master

However, I'd like to know if there is a way to make the output of git log --decorate completely unambiguous as to whether I'm in detached-HEAD state or not.

Example

Say I'm on master and my history looks as follows:

4d860e9 (HEAD, master) Remove trailing whitespace
9a2ef02 Correct typo in header
f0badb5 Add to-do section to README

Case 1: unambiguous detached-HEAD state

If I run

git checkout 9a2ef02

then the output of git log --decorate --oneline is

9a2ef02 (HEAD) Correct typo in header
f0badb5 Add to-do section to README

Because no branch reference is listed next to HEAD in this output, I know for sure that I've got a detached HEAD.

Case 2: detached-HEAD state or not?

However, if I run

git checkout 4d860e9

then HEAD does not point to master, but directly to commit 4d860e9, which master also points to; I've got a detached HEAD. However, there is no way to tell from the output of git log --decorate --oneline,

4d860e9 (HEAD, master) Remove trailing whitespace
9a2ef02 Correct typo in header
f0badb5 Add to-do section to README

because it's exactly the same as when I'm on master.

Is there a way, via some git log options, to remove that ambiguity? I haven't found a way in the git-log man page...

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
jub0bs
  • 60,866
  • 25
  • 183
  • 186

2 Answers2

4

With Git 2.4+ (Q2 2015), git log --decorate will shows the exact branch associated with HEAD (or the lack thereof, for a detached HEAD).

See commit 51ff0f2 by Junio C Hamano (gitster):

log: decorate HEAD with branch name

Currently, log decorations do not indicate which branch is checked out and whether HEAD is detached.

When branch foo is checked out, change the "HEAD, foo" part of the decorations to "HEAD -> foo". This serves to indicate both ref decorations (helped by the spacing) as well as their relationshsip.

As a consequence, "HEAD" without any " -> " denotes a detached HEAD now.

This means the 2.4 release notes now include the following Backward compatibility warning(s):

Output from "git log --decorate" (and "%d" format specifier used in the userformat "--format=<string>" parameter "git log" family of command takes) used to list "HEAD" just like other tips of branch names, separated with a comma in between. E.g.

$ git log --decorate -1 master
commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master)
...

This release updates the output slightly when HEAD refers to the tip of a branch whose name is also shown in the output.
The above is shown as:

$ git log --decorate -1 master
commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD -> master)
...
IMSoP
  • 89,526
  • 13
  • 117
  • 169
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Yes; that's a welcome improvement. I believe I played [a (small) part](http://thread.gmane.org/gmane.comp.version-control.git/263922) in this :) – jub0bs Mar 23 '15 at 10:17
  • 1
    @Jubobs well done! I just don't understand why this thread (http://comments.gmane.org/gmane.comp.version-control.git/263922) starts with "As of Git 2.3.0"? Was it ok *before* Git 2.3.0? – VonC Mar 23 '15 at 10:36
  • Poor choice of words on my part; Junio Hamano also got confused by the wording. What I meant is: "We're now at Git 2.3.0, and this feature has yet to be implemented." – jub0bs Mar 23 '15 at 10:39
2

[Edit: since Git 2.4, well, see VonC's answer. The text below is for versions of Git before 2.4.]

Unfortunately, no. I keep wishing git log's --decorate used my HEAD= syntax. If it did, you would get:

4d860e9 (HEAD, master) Remove trailing whitespace
9a2ef02 Correct typo in header
f0badb5 Add to-do section to README

when you you're in detached-HEAD state, but you would get this instead:

4d860e9 (HEAD=master) Remove trailing whitespace
9a2ef02 Correct typo in header
f0badb5 Add to-do section to README

otherwise.

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
torek
  • 448,244
  • 59
  • 642
  • 775
  • For information, I asked the Git dev team whether they would consider this a good feature on the mailing list: http://marc.info/?l=git&m=142412655130612&w=2 – jub0bs Feb 16 '15 at 23:43
  • Your answer was correct at the time, but I'd like to give more visibility to the new state of affairs. Forgive me for unaccepting your answer. – jub0bs Mar 11 '16 at 17:10
  • 1
    @Jubobs: That's how it goes, with software that is actively changing. Oh well. :-) – torek Mar 11 '16 at 18:07