Re: Distinguishing trivial and non-trivial merge commits

From: Eli Barzilay <eli@barzilay.org>
Date: May 2, 2010, 23:23 UTC
Message-ID: <19422.2438.637578.793734@winooski.ccs.neu.edu>
In-Reply-To: <7vwrvlucls.fsf@alter.siamese.dyndns.org>

On May  2, Junio C Hamano wrote:

Show 16 quoted lines

> Eli Barzilay <eli@barzilay.org> writes:
> 
> > 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.
> 
> You need to be careful here.
> 
> If you see a conflicted hunk and the result ends up being the same
> from one of the parents in that area, then the _result_ is trivial
> as far as the merge (and hence --cc) is concerned, even though you
> may have spent considerable braincycle to stare at the conflict to
> decide that taking a change from one side is the right thing to do.

Yes, that's clear to me now -- thanks.

> You keep saying "manual resolutions", but --cc doesn't have much to
> do with the resolution being manual, nor if the initial mechanical
> merge attempt left conflict markers.

(Right, my original terminology was broken...)

> You would need to redo the merge to find that out, and it can be
> fairly cheaply done with a temporary index and an empty temporary
> working tree elsewhere in the filesystem.

The thing is that I spent so much time for something that is "only the notification emails"... And doing something like this sounds like it requires knowing more git bits. Is there something similar to this somewhere that I can stare at to see how it's done? Pointers would be much appreciated.

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