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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2014, 23:04 UTC
Message-ID: <xmqq1tzi7a4c.fsf@gitster.dls.corp.google.com>
In-Reply-To: <cover.1391549294.git.tr@thomasrast.ch>

Thomas Rast <tr@thomasrast.ch> writes:

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

Yay ;-)

Show 5 quoted lines

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

Show 5 quoted lines

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