Re: [RFD] annnotating a pair of commit objects?
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Jan 3, 2013, 10:23 UTC
- Message-ID
- <50E55C2A.1090204@kdbg.org>
- In-Reply-To
- <7vr4m2ycij.fsf@alter.siamese.dyndns.org>
Am 03.01.2013 08:03, schrieb Junio C Hamano:
Show 23 quoted lines
> 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