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

From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>,
	"William Duclot" <william.duclot@gmail.com>
Cc: <git@vger.kernel.org>
Subject: Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users
Date: Sun, 16 Jul 2017 12:39:16 +0100	[thread overview]
Message-ID: <7E67FF115BB146A49D486E77404882F2@PhilipOakley> (raw)
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
> 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] 