From: Stephen Leake Date: Sat, 01 Mar 2014 10:32:29 GMT Subject: Re: [RFC 0/3] Make git more user-friendly during a merge conflict Message-ID: <85vbvyxl8i.fsf@stephe-leake.org> In-Reply-To: <87eh2n16sw.fsf@fencepost.gnu.org> David Kastrup writes: > Stephen Leake writes: > >> David Kastrup writes: >> >>> Stephen Leake writes: >>> >>>> David Kastrup writes: >>>> >>>>> "do the right thing" commands also tend to do the wrong thing >>>>> occasionally with potentially disastrous results when they are used >>>>> in scripts where the followup actions rely on the actual result. >>>> >>>> That is bad, and should not be allowed. On the other hand, I have yet >>>> to see an actual use case of bad behavior in this discussion. >>> >>> Huh. >>> >>> >> >> That's about backward incompatibility, which is bad, but not what I was >> talking about above. > > No, it isn't. I quote: > > I sometimes run "git reset" during a merge to only reset the index > and then examine the changes introduced by the merge. With your > changes, someone doing so would abort the merge and discard the > merge resolution. I very rarely do this, but even rarely, I > wouldn't like Git to start droping data silently for me ;-). > > You should not make statements like "I have yet to see an actual use > case of bad behavior in this discussion" when you actually mean "I have > not yet seen anything I would be interested in doing myself". Clearly I misunderstood your point. Merely repeating the same statement that I misunderstood, and adding a misunderstanding of what I said, is not helpful. So let me see if I can expand on your use case: - you do 'git merge', which results in conflicts - you edit some workspace files to resolve some of those conflicts (I added this step later, since it was implied but not explicit) - you do 'git reset', intending 'git reset --mixed' (because that is the current default) Actually, I can't find a precise definition of 'git reset'. Here is the synopsis from the man page for 'git-reset' (from git 1.7.9): git reset [-q] [] [--] ... git reset (--patch | -p) [] [--] [...] git reset (--soft | --mixed | --hard | --merge | --keep) [-q] [] In 'git reset', there is no path, so it must be the second or third form. But those _require_ one of the -- options. So 'git reset' is illegal. Clearly something is wrong here; apparently the third line should be: git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [] with '--mixed' as the default, as is stated later. (perhaps the original intent was to not have a default for the third form, but that got changed sometime?). This command "resets the index" but not the working tree. I'm not clear what "reset the index" means here; does it mean "remove all entries from the index", or "reset the index to some previous state"? In other man pages, "reset" can have either meaning depending on context. - then you "examine changes introduced by the merge". I don't know what this means in detail. Before resetting the index, you could diff a workspace file against either HEAD or index. Now you can only diff against HEAD, so I don't understand why you wanted to reset the index. That's not relevant to this use case; I'll just accept that resetting the index is a useful thing to do here. But I would like to understand why. - with the "do the right thing" patch, 'git reset' does 'git reset --merge' instead That "Resets the index and updates the files in the working tree that are different between and HEAD". "" in this case defaults to HEAD, so the working tree is not changed. So as I understand it, this does _not_ lose your conflict resolutions. In fact, it now seems that 'git reset --mixed' is always the same as 'git reset --merge'. So I must be missing something! -- -- Stephe