Subject: Re: [PATCH 0/9] remerge diff proof of concept/RFC

From: Junio C Hamano <[email-masked]>
Date: Tue, 04 Feb 2014 15:04:35 -0800

Thomas Rast <[email-masked]> writes:

>   log --remerge-diff: show what the conflict resolution changed

Yay ;-)

> This series explores another angle, which I call "remerge diff".  It
> works by re-doing the merge in core, using features from patches 1-3
> and 7.  Likely that will result in conflicts, which are formatted in
> the usual <<<<<<< way.  Then it diffs this "remerge" against the
> merge's tree that is recorded in history.

Yup, that is the obvious way to recreate what would have been shown
to the person who recorded the merge result.  I like that approach.

> So I would welcome comments, and/or better ideas, on the following
> proposed resolution:
>
> * Implement what I described last, to take care of delete/modify
>   conflicts.

Naively, I would have thought that

 - If the recorded result of the merge does not have the path, then
   show the deletion of the contents relative to the side that
   modified it.

 - If the recorded result of the merge has the path, then show the
   change between the side that modified it and the recorded result.

might be more useful.  Then we will know what we lost in full (if
the recorded result is to "delete" it), but it is very likely that
we won't see anything if the recorded result blindly took what the
modifying side left.  Comparing with the synthetic stages 2+3 will
at least show us there was something funky going on, so your
approach would be reasonable in this case.

> * Punt on more complex conflicts, by removing those files from the
>   index, and emitting a warning about those files instead.

Sensible.