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

Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 13, 2009, 22:46 UTC
Message-ID
<7vhbu2syi6.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20091013215751.GA12603@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:
>
>> I personally think that the real issue is that our "detached HEAD" message 
>> is still too scary, and what we really want is to issue the scary message 
>> when using "git commit" to move a detached HEAD from what was checked out 
>> to a new commit. So:
>
> This has been discussed before (I happen to agree with you, but you
> probably want to address other comments in the thread):
>
>   http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213

I just re-read the discussion again (thanks for a useful pointers). I mostly agree with everything said in the thread and obviously agree with its conclusion, but one thing I noticed that everybody (who _was_ a git expert) in the thread was assuming bothered me somewhat.

In this sequence:
    1$ git checkout $commit_name_that_is_not_a_local_branch
    2$ git commit; hack; hack; hack;...
    3$ git checkout $branch_name

Step #1 is where the HEAD is detached. It is correct to argue that detached HEAD is a different state and we should inform unsuspecting users, which we do.

Step #2 is where a commit that is not connected to any ref is made.

Step #3 is where the state built in the detached HEAD "branch" vanishes into lost-found.

The experts argued that #3 is where it is dangerous, and while it is technically correct, an unsuspecting non-expert would not even _know_ that nothing dangerous is happening while in step #2.

If the commit name used in step #1 were "v1.0.0", and if the user while in step #2 ran "gitk v1.0.0" (or "git log v1.0.0"), he will be confused by not seeing the recent commits. The distinction between "detached HEAD" and being on a branch needs to be understood to appreciate this (and taken advantage of, when running e.g. "git show-branch v1.0.0 HEAD").

Way before step #3, such a user, even though technically not in any danger yet, would be confused and panic: "I wanted to fix something in the 1.0.0 release, but where did my fix go?"

The current message in step #1 reads like this:
    $ git checkout origin/next
    Note: moving to 'origin/next' which isn't a local branch
    If you want to create a new branch from this checkout, you may do so
    (now or later) by using -b with the checkout command again. Example:
      git checkout -b <new_branch_name>
    HEAD is now at 9ecb2a7... Merge branch 'maint'

And perhaps for people who do not understand the second point in the four-point list [*1*] I showed earlier in the thread, "If you want to create a new branch" may not be descriptive enough, as a sight-seer and an occasional typofixer, the user does not know what branch is good for to begin with, and would not be able to tell if s/he even "wants to create" one. Perhaps it would help more if we reworded three lines after "Note:" with something like:

    To keep the history of commits you will build from now on in a branch,
    you may want to do "git checkout -b <new-branch-name>" now.

and customize the "in a branch" and <new-branch-name> part if the checkout was given a remote tracking branch and the corresponding local branch does not yet exist, e.g. in the above example:

    To keep the history of commits you will build from now on in 'next'
    branch, you may want to do "git checkout -b next" now.
[Footnote]
*1* The world model in which a git user works is:
 * You clone and get copies of where the other end has its branches;
 * You do all your work on your local branches;
 * You may incorporate what the other end further did by merging from the
   tracking branch from it;
 * You update the other end by pushing what you did on your local branches.
I do not think you can nor should hide them from the user [*2*].

*2* We had to repeat "don't hide but teach" many times until it finally sank in for another essential thing in the git world model. I hope we do not have to do the same repeating for the above four points. Luckily we do not have to repeat "don't hide but teach" about the index anymore these days.

Previous: Jeff KingNext: Johannes Schindelin
Message 84 of 91 in “builtin-checkout: suggest creating local branch when appropriate to do so”
  1. builtin-checkout: suggest creating local branch when appropriate to do soJay Soffian, Oct 5, 2009
  2. Sverre RabbelierOct 5, 2009
  3. Johannes SchindelinOct 5, 2009
  4. Sverre RabbelierOct 5, 2009
  5. Jay SoffianOct 5, 2009
  6. Jay SoffianOct 5, 2009
  7. Johannes SchindelinOct 5, 2009
  8. Jeff KingOct 5, 2009
  9. Thomas RastOct 6, 2009
  10. Johannes SchindelinOct 6, 2009
  11. Junio C HamanoOct 6, 2009
  12. Johannes SchindelinOct 6, 2009
  13. Junio C HamanoOct 6, 2009
  14. Johannes SchindelinOct 6, 2009
  15. Matthieu MoyOct 6, 2009
  16. Mikael MagnussonOct 6, 2009
  17. Johannes SchindelinOct 6, 2009
  18. Junio C HamanoOct 18, 2009
  19. 1/3 check_filename(): make verify_filename() callable without dyingJunio C Hamano, Oct 18, 2009
  20. 2/3 DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"Junio C Hamano, Oct 18, 2009
  21. Nanako ShiraishiOct 18, 2009
  22. Björn SteinbrinkOct 18, 2009
  23. Nanako ShiraishiOct 18, 2009
  24. Junio C HamanoOct 18, 2009
  25. Björn SteinbrinkOct 19, 2009
  26. 3/3 git checkout --nodwimJunio C Hamano, Oct 18, 2009
  27. Alex RiesenOct 18, 2009
  28. Junio C HamanoOct 18, 2009
  29. Use "--no-" prefix to switch off some of checkout dwimmeryAlex Riesen, Oct 18, 2009
  30. Junio C HamanoOct 18, 2009
  31. Alex RiesenOct 19, 2009
  32. Alex RiesenOct 19, 2009
  33. Junio C HamanoOct 19, 2009
  34. Alex RiesenOct 19, 2009
  35. Junio C HamanoOct 19, 2009
  36. Avery PennarunOct 21, 2009
  37. Nanako ShiraishiOct 21, 2009
  38. Junio C HamanoOct 21, 2009
  39. git checkout --no-guessJunio C Hamano, Oct 21, 2009
  40. Avery PennarunOct 21, 2009
  41. Jay SoffianOct 26, 2009
  42. Avery PennarunOct 26, 2009
  43. Johannes SchindelinOct 22, 2009
  44. Erik Faye-LundOct 22, 2009
  45. Michael J GruberOct 23, 2009
  46. Junio C HamanoOct 24, 2009
  47. David RoundyOct 24, 2009
  48. Junio C HamanoOct 24, 2009
  49. Johannes SchindelinOct 26, 2009
  50. Avery PennarunOct 26, 2009
  51. Jeff KingOct 26, 2009
  52. Avery PennarunOct 26, 2009
  53. Jeff KingOct 26, 2009
  54. Avery PennarunOct 26, 2009
  55. Jeff KingOct 5, 2009
  56. Eugene SajineOct 6, 2009
  57. Junio C HamanoOct 6, 2009
  58. Johannes SchindelinOct 12, 2009
  59. Björn SteinbrinkOct 12, 2009
  60. Thomas RastOct 12, 2009
  61. Junio C HamanoOct 12, 2009
  62. Thomas RastOct 13, 2009
  63. Junio C HamanoOct 13, 2009
  64. Junio C HamanoOct 13, 2009
  65. Thomas RastOct 13, 2009
  66. Junio C HamanoOct 13, 2009
  67. Johannes SchindelinOct 13, 2009
  68. Junio C HamanoOct 13, 2009
  69. Jeff KingOct 13, 2009
  70. Johannes SchindelinOct 13, 2009
  71. Jay SoffianOct 14, 2009
  72. Junio C HamanoOct 14, 2009
  73. Jay SoffianOct 14, 2009
  74. Junio C HamanoOct 14, 2009
  75. Uri OkrentOct 25, 2009
  76. Jeff KingOct 14, 2009
  77. Thomas RastOct 14, 2009
  78. Jakub NarebskiOct 14, 2009
  79. Johannes SixtOct 13, 2009
  80. Daniel BarkalowOct 13, 2009
  81. Junio C HamanoOct 13, 2009
  82. Daniel BarkalowOct 13, 2009
  83. Jeff KingOct 13, 2009
  84. Junio C HamanoOct 13, 2009
  85. Johannes SchindelinOct 13, 2009
  86. Thomas RastOct 14, 2009
  87. Johannes SchindelinOct 16, 2009
  88. Thomas RastOct 16, 2009
  89. Uri OkrentOct 25, 2009
  90. Junio C HamanoOct 26, 2009
  91. Björn SteinbrinkOct 13, 2009

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.