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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
   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]



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux