Re: Distinguishing trivial and non-trivial merge commits

Eli Barzilay wrote:

On May  2, Jonathan Nieder wrote:

quoted

Note that most conflicts will not show up here: if the merge result
matches either parent, then git diff --cc and friends will not
consider it interesting at all.

Isn't that a good definition of a trivial commit?  I'm not talking
about the whole commit -- just any file that is not identical to one
of its parents.

[...]

For my purpose, I basically just want
to know whether there was manual tweaking involved in the merge.

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

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.

 git show --pretty=format:"" --name-only "$r" | grep -q "."
   --> test if it's trivial

I would have expected

	git show --name-only --exit-code --quiet "$r"

to take care of this, but apparently it always exits zero.  Probably
no one had tried it before.

(My script generally "compensates" for git being fast by running a ton
of them for each email...)

:)

Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/89415