Thomas Rast <t...@thomasrast.ch> writes:
> log --remerge-diff: show what the conflict resolution changed
> 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
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
- 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html