Re: Improving merge of tricky conflicts

From: Sergey Organov <sorganov@gmail.com>
Date: Jul 24, 2020, 22:11 UTC
Message-ID: <87tuxwimvm.fsf@osv.gnss.ru>
In-Reply-To: <xmqq7duslkp0.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 22 quoted lines

> Sergey Organov <sorganov@gmail.com> 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%.

Show 14 quoted lines

> 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