Re: Distinguishing trivial and non-trivial merge commits

From: Eli Barzilay <eli@barzilay.org>
Date: May 2, 2010, 21:03 UTC
Message-ID: <19421.59529.849850.968565@winooski.ccs.neu.edu>
In-Reply-To: <m31vdugj2t.fsf@localhost.localdomain>

On May  2, Jakub Narebski wrote:

Show 5 quoted lines

> 
> Well, the compact combined output is thought in such way that "git
> diff --cc" should be empty except for evil merges, when change comes
> from neither of parents.  See description of --cc format in
> git-diff(1) manpage.

Is there a way to convince `git diff' to show *only* these diffs? Hopefully something that will also play with --stat... Actually, I'm fine with `git show' instead -- and it does show these things, but if I add a --stat it shows all changed files again.

On May  2, Jonathan Nieder wrote:

Show 8 quoted lines

> 
> diff --name-only follows exactly the example heuristic you
> described.  It still does not catch all manual merge resolutions[1].
> 
> Sometimes two branches introduce different changes to completely
> separate parts of a file.  This is not a conflict, and diff --cc
> will correctly report the merge as trivial (whereas diff --name-only
> does not pay enough attention to do the same).

Good -- the first paragraph is what I thought it would do, the second makes it even better. Perhaps it would be nice to show such manual reoslutions from one parent, but I think that that certainly qualifies as stuff that is much less interesting than work that was done to combine content inside a file, or one of those evil merges. (Since it's a notification script -- so I really want it to highlight only "real" work that was done.)

Show 7 quoted lines

> On the other hand, sometimes two branches introduce conflicting
> changes, but the correct resolution for each conflict hunk is to
> pick one as winner.  Though simple, this can be error-prone, because
> rejecting one change from branch A might end up breaking another
> change that was accepted from the same branch.  diff --cc examines
> only the selected revision and its parents and for all it knows,
> this is just another trivial merge.

To translate the "danger" here, I think that if one person commits some changed files, another one does a merge with the earlier content and essentially re-commits all previous versions -- undoing this commit -- IIUC, then in this case my strategy wouldn't show anything. I think that what I do would work "well enough", since such things would be rare to do (eg, it makes more sense to merge first, then another commit that undoes the changes), and in any case there's also the overall push diff, and those changes would show up there.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!