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

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

From
KKKonstantin Khomoutov <kostix+git@007spb.ru>
Date
May 11, 2017, 10:28 UTC
Message-ID
<20170511102812.3ed3sqycjmapfj35@tigra>
In-Reply-To
<61C67DC73308BD49B2D4B65072480DBA2BDAB97D@DEERLM99EZ1MSX.ww931.my-it-solutions.net>
On Thu, May 11, 2017 at 10:10:05AM +0000, Kerry, Richard wrote:
[...]
Show 18 quoted lines
> > > @@ -1940,7 +1940,7 @@ static void am_resolve(struct am_state *state)
> > >
> > >     if (unmerged_cache()) {
> > >             printf_ln(_("You still have unmerged paths in your index.\n"
> > > -                   "Did you forget to use 'git add'?"));
> > > +                   "You might want to use 'git add' on them."));
> >
> > This case is *not* an "rhetorical question is the most succinct way to convey
> > the information" situation; I think this rewrite is a definite improvement.
> > "You might want to 'git add' them" may be more succinct, though.
> 
> "You might want to use 'git add' on them." It isn't about what you
> *want* to use, it's what you *need* to use, isn't it?  And I'm not
> happy about "on them".  I'm not sure quite why, but the phrasing seems
> odd.  How about "You might need to use 'git add'.", or "You might need
> to use 'git add' first.", or "'git add' needs to be used to add
> files." ,  or "'git add' needs to be used before any other git command
> may be used.".
Why not just
  You should run `git add` on each file with resolved conflicts to mark
  them as such.

I'm not an English speaker but IMHO this phrasing concentrates on the essense of the problem. It's far from being succint, unfortunately.

I also wonder what to do with "deleted by them" state of certain files which are also "unmerged" but `git add`-ing them would be a wrong thing to do if we want to accept the upstream's decision to delete the file. So maybe something like

  You might run `git rm` on a file to accept "deleted by them" for it.
appended to the original hint would be good.
Previous: Kerry, RichardNext: Ævar Arnfjörð Bjarmason
Message 27 of 41 in “usability: don't ask questions if no reply is required”
  1. 1/4 usability: don't ask questions if no reply is requiredJean-Noel Avila, May 3, 2017
  2. 2/4 usability: fix am and checkout for nevermind questionsJean-Noel Avila, May 3, 2017
  3. Jonathan NiederMay 3, 2017
  4. Jean-Noël AVILAMay 3, 2017
  5. 3/4 read-tree.c: rework UI when merging no treesJean-Noel Avila, May 3, 2017
  6. Jonathan NiederMay 3, 2017
  7. Jean-Noël AVILAMay 3, 2017
  8. 4/4 git-filter-branch: be assertative on dying messageJean-Noel Avila, May 3, 2017
  9. Jonathan NiederMay 3, 2017
  10. Jonathan NiederMay 3, 2017
  11. Stefan BellerMay 3, 2017
  12. Jean-Noël AVILAMay 3, 2017
  13. 1/3 usability: don't ask questions if no reply is requiredJean-Noel Avila, May 3, 2017
  14. 2/3 read-tree -m: make error message for merging 0 trees less smart aleckJean-Noel Avila, May 3, 2017
  15. Junio C HamanoMay 11, 2017
  16. read-tree: "read-tree -m --empty" does not make senseJunio C Hamano, May 11, 2017
  17. 3/3 git-filter-branch: make the error msg when missing branch more openJean-Noel Avila, May 3, 2017
  18. Junio C HamanoMay 11, 2017
  19. Kerry, RichardMay 4, 2017
  20. Ævar Arnfjörð BjarmasonMay 4, 2017
  21. Kerry, RichardMay 4, 2017
  22. Jean-Noël AVILAMay 9, 2017
  23. Ævar Arnfjörð BjarmasonMay 9, 2017
  24. Jean-Noël AVILAMay 4, 2017
  25. Junio C HamanoMay 11, 2017
  26. Kerry, RichardMay 11, 2017
  27. Konstantin KhomoutovMay 11, 2017
  28. Ævar Arnfjörð BjarmasonMay 11, 2017
  29. 1/3 usability: don't ask questions if no reply is requiredJean-Noel Avila, May 11, 2017
  30. 2/3 read-tree -m: make error message for merging 0 trees less smart aleckJean-Noel Avila, May 11, 2017
  31. Jonathan NiederMay 11, 2017
  32. Junio C HamanoMay 12, 2017
  33. Jean-Noël AVILAMay 12, 2017
  34. 3/3 git-filter-branch:Jean-Noel Avila, May 11, 2017
  35. Junio C HamanoMay 12, 2017
  36. 1/3 usability: don't ask questions if no reply is requiredJean-Noel Avila, May 12, 2017
  37. 2/3 read-tree -m: make error message for merging 0 trees less smart aleckJean-Noel Avila, May 12, 2017
  38. 3/3 git-filter-branch: be more direct in an error messageJean-Noel Avila, May 12, 2017
  39. Junio C HamanoMay 12, 2017
  40. Johannes SixtMay 13, 2017
  41. Junio C HamanoMay 15, 2017

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.