On 16/07/17 12:39, Philip Oakley wrote: > > 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] 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
