Re: [PATCH 2/2 - RFH/WIP] xdiff-merge: optionally show conflicts in "diff3 -m" style

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 31, 2008, 18:42 UTC
Message-ID: <7vd4jp2fi5.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.10.0808311021120.12958@nehalem.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 16 quoted lines

> On Sun, 31 Aug 2008, Junio C Hamano wrote:
>> ...
>> My observation so far suggests that it would be best for me to leave the
>> configuration "merge.conflictstyle" to the default "merge", and instead
>> give an option to allow me to tell "git checkout -m -- $path" (which is
>> also a new feature; it overwrites the $path by the result of a fresh merge
>> to reproduce the conflicted state in the working tree, using the three
>> stages recorded in the index) to use "diff3 -m" style, when I want to.
>
> Now *this* I think is a great idea! 
>
> The reason I think it's a great idea is that it solves so many _different_ 
> issues (which is the mark of a really good solution):
> ...
>  - it fixes another totally unrelated problem: incorrect merge 
>    resolutions.

I do not know if rerere often kicks in in your workflow, but occasionally I notice that I have a faulty merge recorded by it, which automatically is applied again when reproducing a merge. And it makes me deeply regret that I invented the rerere mechanism.

The best solution for this issue I found so far is embarrasingly clumsy. Run "ls -tl .git/rr-cache" to find the newest one with "thisimage", make sure it is the right one, remove the directory and redo the merge.

Actually, the feature of "git checkout -m -- $path" to reproduce the merge for the named path was conceived to address this "I cannot easily correct the faulty resolution that was re-applied" issue.