Junio C Hamano <gitster@xxxxxxxxx> writes: > Sergey Organov <sorganov@xxxxxxxxx> writes: > >>> If your merge used the merge (as opposed to diff3) style, and seeing >>> that the resulting conflict is not easy to review and you wish you >>> used diff3 style instead, it is way too late for any option to "git >>> merge" to help you. >> >> $ git merge --abort >> $ git merge --conflict=diff3 side-branch >> >> or, say, entirely imaginary: >> >> $ git merge --redo --conflict=diff3 side-branch -- my-file >> >> if merge had --redo option and path limiting support, that could be >> handy for other reasons as well, as I have already pointed elsewhere and >> you disagreed, but still. > > You are ignoring the case where you may have successfully resolved > conflicts in some paths before you noticed conflicts in some > particular files are hard to see in one style and wish if you used > the other style, I think. I believe I'm not, or if I do, then you are ignoring the opposite case that you may need to redo entire merge with different merge style output. In other words, I only aimed at decreasing 100% down to at most 80% in your claim: >>> so configuration variable makes 100% more sense than an option >>> to "git merge". because you can only claim 100% if nobody ever needs to redo the merge from scratch, that is obviously not the case. > Surely, you can reset everything away and redo it from scratch, > which is what all of the above is, No, only first two commands are reset and redo everything from scratch, whereas the third command supposedly only affects 'my-file' path: $ git merge --redo --conflict=diff3 side-branch -- my-file Anyway, my primary point was that I still might wish to do exactly reset and start from scratch, and then I miss --conflict option, that in turn makes its existence less than 100% less sense than configuration variable, my estimation being about 80%. > but then you would need a way to stash away the successful half > resolution so far before discarding them. Compared to that, "ouch, I > screwed up and want a freshly conflicted state back for these paths" > would allow you revert only the botched paths without discarding the > work you have already done. > >> Actually, "git checkout" is not the place where I'd expect to find this >> feature in the first place, so to me it's rather already 99% >> illogical. > > One half of the "checkout" (which now exists as a synonym "restore") > is to update the working tree files out of various sources, and > "conflicted stages in the index" is one of them, so it entirely is > natural and logical home for the feature. I believe I already agreed it makes sense the feature ends up being there, and I perfectly understand this /after/ I learned it's there, but I'm still afraid I'd not figure out to look for it there in the first place. > The documentation needs updating to help you and others feel it > natural, I would think. This seems to be mostly the matter of > better education. Yeah, it's education that helps most when things get unintuitive enough. Better documentation always helps indeed, and description of --conflict option in "man git-merge" would be the best place to put a reference to "git checkout -m" (or should it rather be "git restore -m" nowadays?) that you've suggested elsewhere in this thread ;-) Thanks, -- Sergey
