Re: History over-simplification

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 25, 2007, 22:42 UTC
Message-ID: <7v4phi4b9t.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20070923044628.GA3099@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 12 quoted lines

> I don't really like the patch to revision.c because it winds up
> showing trivial merges too.  What I really want is to have the
> "--full-history" option include a merge if either of the following
> is true:
>
>  a) The resulting path does not match _any_ of the parents.  We
>     already handle this case correctly in revision.c and correctly
>     show the "evil" merge.
>
>  b) The resulting path matches one of the parents but not one of
>     the others.  In such a case the merge should still be output if
>     a 3-way read-tree would not have chosen this result by default.

I am not sure (b) is useful in general. Merging two branches that fix the same issue but in different ways (think: 'maint' and 'master' have different infrastructure and a fix initially made on 'master' was backported to 'maint', and then later 'maint' needed to be merged to 'master' to carry forward other fixes) is a norm, and in such cases taking the version from the merged-to branch is almost always what happens.

Also it sounds to me by "if read-tree would not have chosen this result by default" you mean this feature would not just need to run merge-base but also recursive merge-base synthesis, and also recreate the structural merge (aka "rename detection") there as well. Even if (b) is useful, it sounds like a very expensive option, and the current merge-recursive code is structured in such a way to be easily reused for this purpose.