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

Re: [PATCH v2] git-mv: improve error message for conflicted file

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 20, 2020, 18:28 UTC
Message-ID
<xmqqh7u29h2z.fsf@gitster.c.googlers.com>
In-Reply-To
<pull.678.v2.git.1595225873014.gitgitgadget@gmail.com>
"Chris Torek via GitGitGadget" <gitgitgadget@gmail.com> writes:
>     I put in the shortened "conflicted" here but did not shorten the
>     existing "not under version control" message (to minimize the visible
>     and translations-required changes).

It does not matter all that much but the message in your original for the new case looked better and worse at the same time ;-)

"not under version control" is a statement of fact that does not hint what the user may want to do with that information. Your original for the new case gave that hint (i.e. "must resolve first") but the new "the path is unmerged" (I think 'unmerged' is a more proper term for this than 'conflicted'; see gitglossary[7]) stops at stating fact without giving further hint,and in that sense the messages are consistent with each other.

We could shoot for consistency in the opposite direction, by making "not under version control" could instead say "must add first". But that leads to a fruitless comparison between "'git add' then 'git mv'" and "plain 'mv' then 'git add'". For "git mv", "must resolve first" may be the only sane option right now, so it probably is OK.

So, after having thought the above through, I tend to (slightly) prefer to stop at stating fact, perhaps "the path is unmerged" or something to match "not under version control".

>     I like the idea of renaming all stages and keeping them at their current
>     stages, but that's too much for this patch.

I totally agree, and I am not 100% convinced that the "rename all at their current stage" gives a better end-user experience. For one thing, I suspect that it would still have to fail depending on how the destination path and paths that conflict with it are populated in the index, and that may make even harder-to-explain error case.

>     I'll be traveling next week and not sure if I will get to any followups
>     for a while.

That is perfectly fine. We are in pre-release freeze and this patch won't go anywhere until the end of the month.

Thanks for contributing, and safe travels.
Previous: Chris Torek via GitGitGadget
Message 11 of 11 in “git-mv: improve error message for conflicted file”
  1. git-mv: improve error message for conflicted fileChris Torek via GitGitGadget, Jul 17, 2020
  2. Eric SunshineJul 17, 2020
  3. Chris TorekJul 18, 2020
  4. Eric SunshineJul 18, 2020
  5. Junio C HamanoJul 18, 2020
  6. Elijah NewrenJul 18, 2020
  7. Junio C HamanoJul 18, 2020
  8. Elijah NewrenJul 19, 2020
  9. Junio C HamanoJul 19, 2020
  10. git-mv: improve error message for conflicted fileChris Torek via GitGitGadget, Jul 20, 2020
  11. Junio C HamanoJul 20, 2020

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.