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]