Re: Distinguishing trivial and non-trivial merge commits

On May  2, Jakub Narebski wrote:

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:

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

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!