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

Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users

From
Philip Oakley <philipoakley@iee.org>
Date
Jul 16, 2017, 11:39 UTC
Message-ID
<7E67FF115BB146A49D486E77404882F2@PhilipOakley>
In-Reply-To
<xmqq4luh1gzw.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Wednesday, July 12, 2017 10:29 PM
Show 34 quoted lines
> William Duclot <william.duclot@gmail.com> writes:
>
>>>  - The original said "When you have resolved this problem", without
>>>    giving a guidance how to resolve, and without saying what the
>>>    problem is.  The updated one says "conflict" to clarify the
>>>    "problem", and suggests "git add" as the tool to use after a
>>>    manual resolition.
>>>
>>>    Modulo that there are cases where "git rm" is the right tool, the
>>>    updated one is strict improvement.
>>
>> I also wrote "<conflicted_file>" when there could be several. Maybe
>> 'mark it as resolved with "git add/rm"' would be a better (and shorter)
>> formulation?
>
> Another potential source of confusion is if we are seeing "a"
> conflict, or multiple ones.  I'd say it is OK to treat the whole
> thing as "a conflict" that Git needs help with by the user editing
> multiple files and using multiple "git add" or "git rm".  So "mark
> it as resolved with 'git add/rm'" is fine, I would think, but
> anything that I say about UI's understandability to new people needs
> to be taken with a large grain of salt ;-).
>
>> ... I feel like a lot of git messages could be improved this way
>> to offer a UI more welcoming to inexperienced user (which is a
>> *broad* segment of users). But I am not aware of the cost of
>> translation of this kind of patch: would several patches like this
>> one be welcomed?
>
> Surely, as long as I can depend on other reviewers who are more
> passionate about end-user experience than I am, I'll take such
> patches with their help.
>
> Thanks.

One of the other confusions I had / have (and I have a saved note to remind me) is when rebase stops with a conflict, and asks the user to "fix" it, then ues "--continue".

I always expect that Git will do the 'add' of the resolved conflict because that is what it would do normally as the next step after the merge.

I also had a similar issue with the --allow-empty case of 'nothing added to commit but untracked files present' where I had been expecting the commit to be simply omitted. You have to go through a reset dance before continuing.

Philip [I'll be off line till Friday]

Previous: Junio C HamanoNext: Phillip Wood
Message 5 of 8 in “rebase: make resolve message clearer for inexperienced users”
  1. rebase: make resolve message clearer for inexperienced usersWilliam Duclot, Jul 9, 2017
  2. Junio C HamanoJul 10, 2017
  3. William DuclotJul 10, 2017
  4. Junio C HamanoJul 12, 2017
  5. Philip OakleyJul 16, 2017
  6. Phillip WoodJul 24, 2017
  7. Junio C HamanoJul 24, 2017
  8. Phillip WoodJul 26, 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.