Re: Merge commit diff results are confusing and inconsistent
- Date: Sat, 11 May 2019 15:08:40 +0100
- From: Philip Oakley <philipoakley@xxxxxxx>
- Subject: Re: Merge commit diff results are confusing and inconsistent
On 07/05/2019 15:10, Robert Dailey wrote:
The majority use case I'm interested in is seeing net-positive changes
that happen in merge commits. Normally I take for granted that merge
commits have nothing meaningful in them (meaningful here defined as
something unexpected for a merge commit). But what if someone makes a
poor decision and does some crazy refactoring in 1 file and amends it
into a merge commit? Let's also say that these changes are done to a
file that wasn't modified in any parent (say a unrelated.txt next to
your color.txt). Since neither parent cares about that file for the
purposes of the merge, I am trying to make sense of a revision
specification that can be used to see what they did to that file.
I see that you are specifically interested in seeing 'net-positive' changes.
Part of the problem is that for a merge commit there are multiple
choices as to the implied initial central merge, where A and B are
combined to create X [which I just called the central merge], to which
further changes are made to create the final merge commit C. (Note: X is
never committed, and is somewhat 'mythical')
These cases where there needs to be 'further changes', either to resolve
conflicts because we never got a cleanly merged X, or the user added
changes, we an "Evil Commit/Merge". Definitions vary slightly between
different protagonists in the VCS world as to the best evil merge
For your 'net-positive' changes, what is needed is to effectively
generate that mythical clean initial merge X where either we delete from
both sides, or we have a simple addition only from one side
(addition/deletion normally being of whole lines). It is only that way
that allows the changes from X to C to be addition only.
Unfortunately there is currently no diff representation that does that,
as there is no method of indicating that middle X state. In the worst
case there are always pathological cases.
A similar problem exists for the “reuse recorded resolution” (rerere /
redo) storage of conflict resolutions. At present there isn't a way of
exchanging such resolutions in a mechanism similar to a diff. In fact I
was only just asking about that  within the last two days! There is
some discussion about the rerere database in , should you want a look.
 rerere -