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

Re: Command-line interface thoughts

From
MNMichael Nahas <mike.nahas@gmail.com>
Date
Jun 7, 2011, 02:31 UTC
Message-ID
<BANLkTinE8tCRZ-HFP0uwm6odGNAxjZPXng@mail.gmail.com>
In-Reply-To
<BANLkTi=yytzDrJLvVn_ZhJOiQs-rqvKi1w@mail.gmail.com>
I think NEXT and WTREE should be like tree objects, not commits, so I
would argue that "git show NEXT" should show what it shows for a tree.
 From the man page:
"For trees, it shows the names (equivalent to git ls-tree with --name-only)."

"git diff HEAD NEXT" during a merge conflict: During the merge conflict there are two groups of changing files.  Some files have been resolved and reside in "Stage0".  The others have not been resolved and a copy resides in each of "Stage1", 2, and 3.  (Which I eagerly want to name BASE, HEAD, and MERGE_HEAD.)

My thought is that NEXT should only represent those changing files that have been resolved.  So, NEXT would be HEAD plus the files in Stage0.  So, "git diff HEAD NEXT" would print out the changes in Stage0.

The trickier question for me is what does this make "git diff WTREE NEXT"?  Well, the resolved changes are the same in WTREE and NEXT. The unresolved files in NEXT are the same as in HEAD.  So, "git diff WTREE NEXT" would print out the unresolved changes between WTREE and HEAD.

What I don't like about that is that at the point of conflict in each file, "git merge" has written the changes from HEAD and MERGE_HEAD. So, printing the changes between HEAD and WTREE will resulting in the changes done by HEAD printed twice.  That, while understandable, isn't so pretty.

I've engineered a conflicted merge and taken a look at what "git diff --cached HEAD" and "git diff --cached" looks like.  Can someone confirm that the current behavior is equivalent to what I described above?

Junio asked: So what should it look like during a "pull" that did not finish?

Is this the same as a conflicted merge state?  (Except possibly with FETCH_HEAD instead of MERGE_HEAD.)

Junio asked: "rebase -i"?

I know what this does (and love it!), but not how it works.  I certainly don't know the state it leaves things in when it's conflicted.  I'll let someone else go to bat here.

Teach a noob: What's "rc phase"?
Mike
On Mon, Jun 6, 2011 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 63 quoted lines
>
> Scott Chacon <schacon@gmail.com> writes:
>
> > On Mon, Jun 6, 2011 at 9:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >>>> That is why I asked what the user experience of "git show NEXT" as opposed
> >>>> to "git show INDEX" should look like. So what should it look like during a
> >>>> "pull" that did not finish?
> >>>
> >>> If NEXT is to mean the result of a commit in the current state, and the
> >>> current state would or should not allow a commit, then trying to access
> >>> that pseudo-commit should error out with a helpful message.
> >>
> >> What "helpful message"? I asked for the user experience, not handwaving.
> >>
> >> Do you mean to say that the error message would teach the user that the
> >> current state is not something you can create a commit? What message would
> >> that give the end user?  I am hoping the following is not what will happen:
> >>
> >>  Q. I tried "git show NEXT" because I wanted to see what the next commit
> >>     would look like, but I got an error, saying NEXT is not known as I
> >>     haven't resolved a conflict.
> >>
> >>  A. Yes, the message is correct.
> >
> > I'm not sure why this wouldn't just list out the index tree,...
>
> You are not entitled to say "I'm not sure" ;-). I asked you to show a
> design of the user experience of "git show NEXT", as an advocate for the
> NEXT/WTREE notation.
>
> I'd take it that you would "just list out the index tree" as the outline
> of the user experience.
>
> >>  A. You would say "git diff HEAD NEXT".
> >>
> >>  Q. Ah, that is the same as I always do before making a commit to see what
> >>     I have added so far look sane. Thanks.
> >
> > Why would this look sane? I would think this would say "* Unmerged
> > path <file>" just like 'diff --cached would do.
>
> Either you read it too hastily or I didn't write this clear enough; "sane"
> does not refer to the command. In this story, the novice is saying "Before
> I make a commit, I check if my changes so far matches what I wanted to
> achieve, in other words, I check the sanity of my changes. And 'git diff
> HEAD NEXT' is the command I use when I am not in this weird 'conflicted'
> state. I am happy that I can use the same command".
>
> > But, yes, I assume there would be some difficulty in supporting it
> > everywhere.
>
> I don't care too much about "difficulty in uniformly implementing". I am
> doubting that you can _design_ uniformly for these new tokens to make
> enough sense to help the new people. That is why I've been asking for
> concrete examples of user experience design, sample transcripts, that
> covers known corner cases.
>
> If NEXT/WTREE advocates cannot come up with one, or if that is just to
> punt and say "NEXT is not defined in this case---use the traditional
> command" in the error message, I don't see much point in discussing this
> further. It will end up with the same whine-fest as previous rounds.
>
Previous: Paul EbermannNext: Junio C Hamano
Message 96 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.