git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: master^ is not a local branch -- huh?!?

From
Nicolas Pitre <nico@fluxnic.net>
Date
Jan 30, 2010, 04:39 UTC
Message-ID
<alpine.LFD.2.00.1001292305500.1681@xanadu.home>
In-Reply-To
<ca433831001291959m76ed6adap32a17c10e465af1f@mail.gmail.com>
On Fri, 29 Jan 2010, Mark Lodato wrote:
Show 30 quoted lines
> On Fri, Jan 29, 2010 at 10:11 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Fri, 29 Jan 2010, Mark Lodato wrote:
> >> On Fri, Jan 29, 2010 at 8:22 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> >> > On Fri, 29 Jan 2010, Mark Lodato wrote:
> >> >
> >> >> Still, I find it slightly confusing and unfriendly.  How about the following?
> >> >
> >> >> Checking out commit 'master^0'.
> >> >>
> >> >> Since this is not a local branch head, any commits you make will be lost
> >> >> when you check out another branch or commit.  (In git terminology, HEAD
> >> >> is detached.)  If you just wish to look at files without committing,
> >> >> this is fine.  If you wish to make commits and retain them, you may
> >> >> create a new branch by running:
> >> >>
> >> >>   git checkout -b <new_branch_name>
> >> >
> >> > This gives the impression that any commit you make on a detached HEAD
> >> > are going to be lost, unless you create a new branch first.
> >>
> >> What about "...you may want to create..."?  This does not imply that
> >> creating a new branch now is the *only* way, just the most likely.  If
> >> a user knows another way, that user probably does not need this
> >> warning in the first place.
> >
> > Still, you don't know what way the unsuspected user will take to get
> > there.
> 
> Sorry, I don't understand.  What do you mean by "take to get there"?
> Are you referring to how the user arrived in this detached HEAD state,
Yes.
> or what the user wishes to do next?  Either way, I still am not sure
> why this wording is no good.  Could please elaborate?

First, I'm afraid that "Checking out commit 'foobar'" might be confusing as this may happen through either a remote branch, a tag, or any random commit. It seems to me that "Checking out 'v2.5'" is less confusing than "Checking out commit 'v2.5'". But that's a minor detail and probably a personal preference.

Show 6 quoted lines
>   Note: 'master^0' isn't a local branch head;
> 
> This isn't very friendly.  It sounds like an admonition.  Rather, I
> suggest that the first sentence be similar to, but distinct from,
> "Switched to branch foo," to inform the user that they did something
> different, which may or may not be intentional.

I consider that starting the explanation paragraph with " any commits you make will be lost" is even more unfriendly, and misleading. That is sure to scare people needlessly.

Show 8 quoted lines
>   You are in 'detached HEAD' state. You can look around, make experimental
>   changes and commit them, and you can discard any commits you make in this
>   state without impacting any branches by checking out another branch.
> 
> First, we shouldn't start off with the term "detached HEAD".  I used a
> parenthetical comment to mention it, in case the user wants to look it
> up or refer to this state.  Otherwise, the term conveys no meaning,
> unless one understand enough about git to not need this advice.

To the contrary: this "detached HEAD" is exactly what you need if you want to relate to any documentation or perform a search for more information. Like it or not, this detached HEAD term is exactly what this Git concept is all about and how it is designated everywhere. The sooner Git users see and learn about it the better.

Show 8 quoted lines
> Second, this advice should be a warning that commits may be lost
> unless one knows what one is doing.  Saying "you can discard commits"
> makes it sound like a feature!  Sure, that may be so for advanced
> users, but for beginners (for whom this advice is intended), this is a
> common trap.  I tried to word the advice so that the users will know
> that they should not commit without first creating a branch (or
> knowing what they're doing), but that if they don't commit, there's no
> problem.  The wording quoted above does not convey this meaning to me.

I think your wording is just too far on the negative side, and makes Git look like an even more difficult tool than it actually is. And you help no one by stating things that are not exactly true even if the truth implies that you need to know what you're doing. The _whole_ and only point of a detached HEAD is actually to be able to make commits even without having to create a new branch first.

Show 10 quoted lines
> This discussion brings up another good point: The main worry about a
> detached head is losing commits.  Back in 2008, it was suggested to
> have a warning when committing on a detached HEAD:
> 
> http://kerneltrap.org/mailarchive/git/2008/9/2/3169744
> 
> This was before the advice system, so folks complained about it
> getting in the way, and it was never implemented.  Since we now have a
> way to easily turn off the warning, perhaps we should bring this topic
> up again (probably as a separate thread.)

Possibly. I don't like the message proposed in that patch though. Since the warning when actually detaching HEAD is about to become way more prominent, the per-commit warning doesn't have to be that noisy anymore.

Nicolas
Previous: Mark LodatoNext: Nicolas Pitre
Message 51 of 94 in “master^ is not a local branch -- huh?!?”
  1. Ron1Jan 29, 2010
  2. Jacob HelwigJan 29, 2010
  3. Sverre RabbelierJan 29, 2010
  4. Jacob HelwigJan 29, 2010
  5. Junio C HamanoJan 29, 2010
  6. Sverre RabbelierJan 29, 2010
  7. checkout: warn about 'branch name' rather than 'local branch'Sverre Rabbelier, Jan 29, 2010
  8. checkout: Fix test for s/local branch/branch name/ change.Jacob Helwig, Jan 29, 2010
  9. Sverre RabbelierJan 29, 2010
  10. Nicolas PitreJan 29, 2010
  11. Ron GarretJan 29, 2010
  12. Junio C HamanoJan 29, 2010
  13. Sverre RabbelierJan 29, 2010
  14. Junio C HamanoJan 29, 2010
  15. Nicolas PitreJan 29, 2010
  16. Sverre RabbelierJan 29, 2010
  17. Nicolas PitreJan 29, 2010
  18. Sverre RabbelierJan 29, 2010
  19. Nicolas PitreJan 29, 2010
  20. Junio C HamanoJan 29, 2010
  21. Sverre RabbelierJan 29, 2010
  22. Nicolas PitreJan 29, 2010
  23. Junio C HamanoJan 29, 2010
  24. Jacob HelwigJan 29, 2010
  25. Nicolas PitreJan 29, 2010
  26. Junio C HamanoJan 30, 2010
  27. Sverre RabbelierJan 30, 2010
  28. Junio C HamanoJan 30, 2010
  29. Sverre RabbelierJan 30, 2010
  30. Michael WittenJan 30, 2010
  31. Nicolas PitreJan 30, 2010
  32. Mark LodatoJan 30, 2010
  33. Nicolas PitreJan 30, 2010
  34. Ron GarretJan 30, 2010
  35. Junio C HamanoJan 30, 2010
  36. Ron GarretJan 30, 2010
  37. Nicolas PitreJan 30, 2010
  38. Jay SoffianJan 30, 2010
  39. Junio C HamanoJan 30, 2010
  40. Jay SoffianJan 30, 2010
  41. Nicolas PitreJan 30, 2010
  42. Junio C HamanoJan 30, 2010
  43. Ron GarretJan 30, 2010
  44. Junio C HamanoJan 30, 2010
  45. Jay SoffianJan 30, 2010
  46. Junio C HamanoJan 30, 2010
  47. Ron GarretJan 30, 2010
  48. Mark LodatoJan 30, 2010
  49. Nicolas PitreJan 30, 2010
  50. Mark LodatoJan 30, 2010
  51. Nicolas PitreJan 30, 2010
  52. Nicolas PitreJan 30, 2010
  53. Jay SoffianJan 30, 2010
  54. Nicolas PitreJan 30, 2010
  55. Mark LodatoJan 30, 2010
  56. Junio C HamanoJan 30, 2010
  57. Jeff KingJan 30, 2010
  58. Ron GarretJan 30, 2010
  59. A Large Angry SCMJan 29, 2010
  60. Junio C HamanoJan 29, 2010
  61. Johannes SchindelinJan 30, 2010
  62. Nicolas PitreJan 30, 2010
  63. Johannes SchindelinJan 29, 2010
  64. Ron1Jan 29, 2010
  65. Jacob HelwigJan 29, 2010
  66. Ron GarretJan 29, 2010
  67. Junio C HamanoJan 29, 2010
  68. Ron GarretJan 29, 2010
  69. Junio C HamanoJan 31, 2010
  70. Octavio AlvarezJan 29, 2010
  71. Ron GarretJan 29, 2010
  72. Octavio AlvarezJan 29, 2010
  73. Ron GarretJan 29, 2010
  74. Octavio AlvarezJan 29, 2010
  75. Junio C HamanoJan 29, 2010
  76. Ron GarretJan 29, 2010
  77. Julian PhillipsJan 29, 2010
  78. Ron GarretJan 30, 2010
  79. Ron GarretJan 30, 2010
  80. Junio C HamanoJan 30, 2010
  81. Ron GarretJan 30, 2010
  82. Scott R. GodinJan 29, 2010
  83. Ron GarretJan 29, 2010
  84. Sverre RabbelierJan 29, 2010
  85. Ron GarretJan 29, 2010
  86. Junio C HamanoJan 29, 2010
  87. Ron GarretJan 29, 2010
  88. Michael WittenJan 30, 2010
  89. Junio C HamanoJan 30, 2010
  90. Ron GarretJan 30, 2010
  91. Junio C HamanoJan 30, 2010
  92. Ron GarretJan 30, 2010
  93. Junio C HamanoJan 30, 2010
  94. Ron GarretJan 30, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.