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
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Oct 13, 2009, 23:16 UTC
Message-ID
<alpine.DEB.1.00.0910140108110.4985@pacific.mpi-cbg.de>
In-Reply-To
<7vhbu2syi6.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 13 Oct 2009, Junio C Hamano wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > 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.
> >
> > 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.

We can of course continue to this public wanking session in our nice little circle here on git@vger, fully aware that real users will not dare to interrupt us.

In the alternative, we can go out into the world (you know, that thing behind the computer screen?) and ask somebody who has _not_ been exposed to Git for _4 years_ (like most of you!) just how hard it is to work with Git.

Let me tell you this from my experience: the least likely answer is "the messages are too scary". Invariably, the answer I get is "it is totally unintuitive". Often followed by "I tell Git to do something straight-forward, and it refuses to do it."

Maybe we should just admit that we are no user interface designers, so one cannot expect miracles from us in that respect. And first and foremost, we should not pretend to ourselves that we are good at user interfaces, because we have a track record of sucking in that area. Big time.

Ciao, Dscho

P.S.: As somebody mentioned already, it is time to fix the tools, not our users.

Previous: Junio C HamanoNext: Thomas Rast
Message 85 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.