Re: Improving merge of tricky conflicts

Junio C Hamano [off-list ref] writes:

Sergey Organov [off-list ref] writes:

quoted

quoted

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:

quoted

quoted

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.

quoted

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