Am 03.01.2013 08:03, schrieb Junio C Hamano: > The intended use case is to "go beyond rerere". Given a history of > this shape: > > o---o---o---I mainline > / > O---o---X---o---A topic A > \ > o---Y---o---o---B topic B > > Suppose in the original O we had a function "distimmed_doshes()" to > tell if doshes are already distimmed, with some call sites. On the > branch leading to A, at commit X, this function was renamed to > "doshes_are_distimmed()", and all existing call sites were adjusted. > On the side branch leading to B, however, at commit Y, a new call > site to the old function was added in a file that was not touched > between O..A at all. > > When merging either the topic A or the topic B (but not both) to the > integration branch that did not touch this function or use of it, no > special care needs to be taken, but when merging the second topic > after merging the other one, we need to resolve a semantic conflict. > Namely, the callsite to "distimmed_doshes()" introduced by commit Y > needs to be adjusted to call "doshes_are_distimmed()" instead. I guess this issue comes up when you rebuild pu. Perhaps you (and other integrators with a similar workflow) are sufficiently served with something that resembles rebase -p --first-parent, as proposed here: http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198483 (A proposal of the same idea appeared already years earlier: http://thread.gmane.org/gmane.comp.version-control.git/62782/focus=62794 but its implementation only re-did the merge, which would not help your case.) -- Hannes -- 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