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

Re: Command-line interface thoughts

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 8, 2011, 13:10 UTC
Message-ID
<201106081510.02701.jnareb@gmail.com>
In-Reply-To
<4DECD406.2010009@drmicha.warpmail.net>
On Mon, 6 Jun 2011, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 06.06.2011 14:19:
>> On Mon, 6 June 2011, Michael J Gruber wrote:
>>> Junio C Hamano venit, vidit, dixit 06.06.2011 08:16:
>>>> Scott Chacon <schacon@gmail.com> writes:
[...]
Show 36 quoted lines
>>> That is why the other Michael suggested "NEXT" as opposed to "INDEX":
>>> The index has many aspects, only one of which is "the contents of the
>>> next commit if I would issue 'git commit' right now". (I would even go
>>> so far as using "STAGE".) Now, it's hard to argue that "the result of a
>>> commit" is not tree-like, isn't it? And there's no question what "git
>>> show NEXT" would do. Yes, if you repeat that command, you get a
>>> different sha1 each time (because of the time field).
>>>
>>> I don't think anyone is seriously suggesting to replace the index by a
>>> pseudo commit; but the one aspect which people use most could be well
>>> represented like that, and this might even help emphasizing the
>>> different aspects of the index. Give the index an identity as an
>>> "object" (no, no new type, not in the object db, but as a ui object),
>>> not something mysterious behind the scenes!
>> 
>> So what you suggest would make
>> 
>>   $ git diff NEXT WTREE
>> 
>> behave differently from
>> 
>>   $ git diff
>> 
>> and
>> 
>>   $ git diff HEAD NEXT
>> 
>> behave differently from
>> 
>>   $ git diff --cached
>> 
>> Do you really think that it is good idea?
> 
> I don't know where you're getting from that someone is suggesting to
> make them different. (And even if, it's new UI, not changed.) Everyone's
> been suggesting to make these more accessible.
Here:
  That is why the other Michael suggested "NEXT" as opposed to "INDEX":

It was in response to question how "git diff NEXT WTREE" etc. and "git show NEXT" would look like _in presence of merge conflicts_, as compared to "git diff" etc. and "git ls-files" / "git ls-files --stage".

Show 7 quoted lines
>>> As for WTREE: git diff against work tree does not look at non-tracked
>>> ignored files, so why should WTREE?
>> 
>> So we tailor WTREE do diff behavior?
> 
> There is no WTREE and nothing to tailer. We create it so that it is most
> useful and consistent, whatever that may be.

But what if "most useful" contradicts "consistent" (and "user friendly") and vice versa? That is the problem with designing this UI.

Show 6 quoted lines
>> Besides, isn't this exercise a bit academic?  New to git wouldn't use
>> index, and would use 'git commit -a' and 'git diff'... and that would
>> be enough... well, perhaps except 'git add' + 'git diff'...
> 
> But we want them to grasp and use the git concepts! That is why some of
> us want to make them more accessible.
I don't think that making stage/index and working area look like tree-ish
(which they ain't), or using tree-ish like keyword for some ways of 
accessing/addressing index and worktree would make them grasp git concepts.
 
All the corner cases of proposed UI must be addressed in detail, and
examined to tell if it would make git [concepts] more accessible, or if
it would just move difficulty in other place.
Show 13 quoted lines
>>> Full disclosure: I love the index but hate the way we make it difficult
>>> to use sometimes, and even have to lookup myself what command and option
>>> to actually use if all I want to do is diff A against B, or take the
>>> version of a file from A and write it to B, when A and B are a commit,
>>> the index or the worktree (with a commit being the nonwritable, of course).
>> 
>> Note that in case of saving to worktree you can always use
>> 
>>   $ git show HEAD:./foo>foo
>>   $ git show :0:./foo  >foo     # or just :./foo
> 
> Exactly, yet another command to add to the list below, and it's not even
> all git (because of the shell redirection).
Orthogonality is good in theory, but having more than one way to do
something (like Perl's TIMTOWTDI) is a good thing, especially for UI.
Show 19 quoted lines
>>> I mean, this is really crazy: We have 4 commands ("add", "rm
>>> [--cached]", "checkout [<commit>] --", "reset [<commit>] --") which you
>>> need to be aware of if all you want to do is moving file contents
>>> (content at a path) between a commit, the index and the worktree! And
>>> this is actually worse than having 6 for the 6 cases.
> 
> Add to this craziness the fact that "checkout -- <path>" reads from
> index and writes to worktree, but "checkout <commit> -- path" does not
> read from commit and write to worktree - it reads from commit and writes
> to index+worktree.
> 
> Note that I'm not suggesting to change any of the beloved
> reset/checkout/whatever variants.
> 
> But the more I look at the commit - index - worktree triangle and the
> commands we have the more I realize how messed up the ui is, simply
> because it is determined by the underlying mechanics (e.g.: checkout
> writes the index to the worktree, possibly after updating the index from
> a commit) rather than by the concepts.

Actually it is not determined by underlying mechanics, but by requiring sane behavior. Updating worktree from HEAD without updating index is usually something that you do not want, generating unexpected result.

Also, IMVHO the concepts are simple to understand / remember. All checkout variants check out to working area; all reset variants reset from HEAD / commit:

                 checkout    reset
                  /--^--\   /--^--\
  HEAD              |         ||v
                    |         ||
  index             ||        |v
                    ||        |
  working area      vv        v
And all those update intermediate stages.
Show 9 quoted lines
> And the bad thing is that even when you look at a single command like
> reset or checkout, you can get confused easily because of the multiple
> different functions they overload (e.g. checkout can change HEAD, the
> index and/or the worktree), and also because of some different defaults
> (HEAD vs. index). I think we lost consistency here because over time
> "useful defaults" grew in the wild.
> 
> That is why I'm suggesting concept based variants (move this content
> from A to B, show me the difference between A and B).
Like "git put" proposal by Jeff King (Peff)?
  [RFC/PATCH] git put: an alternative to add/reset/checkout
  http://thread.gmane.org/gmane.comp.version-control.git/175262
-- 
Jakub Narebski
Poland
Previous: Michael J GruberNext: Junio C Hamano
Message 12 of 98 in “Command-line interface thoughts”
  1. Michael NahasJun 4, 2011
  2. Jakub NarebskiJun 4, 2011
  3. Michael NahasJun 5, 2011
  4. Jakub NarebskiJun 5, 2011
  5. Scott ChaconJun 5, 2011
  6. Jakub NarebskiJun 5, 2011
  7. Junio C HamanoJun 6, 2011
  8. Michael J GruberJun 6, 2011
  9. Michael NahasJun 6, 2011
  10. Jakub NarebskiJun 6, 2011
  11. Michael J GruberJun 6, 2011
  12. Jakub NarebskiJun 8, 2011
  13. Junio C HamanoJun 6, 2011
  14. Drew NorthupJun 6, 2011
  15. Junio C HamanoJun 6, 2011
  16. Michael J GruberJun 6, 2011
  17. Junio C HamanoJun 6, 2011
  18. Scott ChaconJun 6, 2011
  19. Junio C HamanoJun 6, 2011
  20. Michael J GruberJun 7, 2011
  21. Jonathan NiederJun 7, 2011
  22. Holger HellmuthJun 7, 2011
  23. Jonathan NiederJun 7, 2011
  24. Jakub NarebskiJun 7, 2011
  25. Holger HellmuthJun 8, 2011
  26. Jakub NarebskiJun 8, 2011
  27. Holger HellmuthJun 9, 2011
  28. Jakub NarebskiJun 10, 2011
  29. Holger HellmuthJun 10, 2011
  30. Jakub NarebskiJun 10, 2011
  31. Holger HellmuthJun 10, 2011
  32. git diff --added (Re: Command-line interface thoughts)Jonathan Nieder, Jun 13, 2011
  33. Miles BaderJun 13, 2011
  34. Miles BaderJun 13, 2011
  35. Jonathan NiederJun 13, 2011
  36. Junio C HamanoJun 13, 2011
  37. Junio C HamanoJun 13, 2011
  38. Holger HellmuthJun 13, 2011
  39. Michael NahasJun 13, 2011
  40. Jakub NarebskiJun 13, 2011
  41. Holger HellmuthJun 13, 2011
  42. Michael HaggertyJun 14, 2011
  43. Jakub NarebskiJun 14, 2011
  44. René ScharfeJun 7, 2011
  45. Jakub NarebskiJun 7, 2011
  46. Jakub NarebskiJun 8, 2011
  47. Michael NahasJun 8, 2011
  48. Jakub NarebskiJun 8, 2011
  49. Michael NahasJun 8, 2011
  50. Jeff KingJun 8, 2011
  51. Michael NahasJun 8, 2011
  52. Jeff KingJun 9, 2011
  53. Michael NahasJun 9, 2011
  54. Jakub NarebskiJun 10, 2011
  55. Jakub NarebskiJun 9, 2011
  56. Michael NahasJun 9, 2011
  57. Jakub NarebskiJun 9, 2011
  58. Jakub NarebskiJun 9, 2011
  59. Michael HaggertyJun 9, 2011
  60. Andreas EricssonJun 9, 2011
  61. Thomas RastJun 9, 2011
  62. Jeff KingJun 9, 2011
  63. Jay SoffianJun 9, 2011
  64. Jeff KingJun 9, 2011
  65. Junio C HamanoJun 9, 2011
  66. Jay SoffianJun 9, 2011
  67. Junio C HamanoJun 9, 2011
  68. Michael HaggertyJun 9, 2011
  69. Junio C HamanoJun 9, 2011
  70. Michael HaggertyJun 9, 2011
  71. Jeff KingJun 9, 2011
  72. Michael HaggertyJun 9, 2011
  73. Jakub NarebskiJun 9, 2011
  74. Michael HaggertyJun 9, 2011
  75. Jakub NarebskiJun 10, 2011
  76. Michael NahasJun 10, 2011
  77. Jakub NarebskiJun 10, 2011
  78. Jeff KingJun 9, 2011
  79. Michael NahasJun 9, 2011
  80. Jeff KingJun 9, 2011
  81. Jakub NarebskiJun 9, 2011
  82. Michael NahasJun 10, 2011
  83. Jeff KingJun 10, 2011
  84. Junio C HamanoJun 10, 2011
  85. Junio C HamanoJun 10, 2011
  86. Jakub NarebskiJun 10, 2011
  87. Michael HaggertyJun 12, 2011
  88. Junio C HamanoJun 12, 2011
  89. Michael NahasJun 12, 2011
  90. Junio C HamanoJun 12, 2011
  91. Michael NahasJun 13, 2011
  92. Jeff KingJun 13, 2011
  93. Jeff KingJun 9, 2011
  94. Paul EbermannJun 5, 2011
  95. Paul EbermannJun 5, 2011
  96. Michael NahasJun 7, 2011
  97. Junio C HamanoJun 7, 2011
  98. Michael NahasJun 7, 2011

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.