Re: Improving merge of tricky conflicts

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 24, 2020, 20:30 UTC
Message-ID: <xmqq7duslkp0.fsf@gitster.c.googlers.com>
In-Reply-To: <874kpxwghu.fsf@osv.gnss.ru>

Sergey Organov <sorganov@gmail.com> writes:

Show 15 quoted lines

>> 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.

Surely, you can reset everything away and redo it from scratch, which is what all of the above is, 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.

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.