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

[Phillip Wood <phillip.wood@talktalk.net>]

On 16/07/17 12:39, Philip Oakley wrote:
> 
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Wednesday, July 12, 2017 10:29 PM
>> 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]

git rebase --continue requiring one to git add first confuses/annoys me
too. I started a patch to autostage unstaged changes if they don't
contain conflict markers a couple of weeks ago, I'll clean it up and
post it later this week.

I also find it confusing that it asks me to edit the commit message for
picks, fixups and non-final squashes after conflicts. I can see that
perhaps one might want to amend the message to reflect any changes that
were made while resolving the conflicts but I've never had too. I'd
rather be able to pass --edit to rebase --continue if I needed to edit
the message in those cases. Looking through the code I think it would
require saving some extra state when rebase bails out on conflicts so
rebase --continue could tell if it should be asking the user to amend
the message.

Best Wishes

Phillip