"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
