Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users
- Date: Sun, 16 Jul 2017 12:39:16 +0100
- From: "Philip Oakley" <philipoakley@xxxxxxx>
- Subject: Re: [PATCH/RFC] rebase: make resolve message clearer for inexperienced users
From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Wednesday, July 12, 2017 10:29 PM
William Duclot <william.duclot@xxxxxxxxx> 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
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)
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.
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.
[I'll be off line till Friday]