Re: [RFC] Applying a graft to a tree and "rippling" the changes through

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 20, 2005, 23:46 UTC
Message-ID: <Pine.LNX.4.63.0511210041370.24681@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20051120223249.GI3393@nowhere.earth>

Hi,

On Sun, 20 Nov 2005, Yann Dirson wrote:

Show 15 quoted lines

> On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:
> > 
> > ORIG1 .. ORIG2 .. .. ORIG_HEAD
> >                          |
> >                          |   GIT1 .. GIT2 .. .. GIT_HEAD
> >                          |   /                    /
> >                          | /                     /
> >                       UNIFYING_MERGE           /
> >                                    \         /
> >                                      \     /
> >                                NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
> > 
> Note: it's not only about research (ie. something that would be static
> for browsing only), it's also about using the results of the research
> in further developement.

Then you could base your future development on NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES.

Show 6 quoted lines

> Well, no doubt this approach can be used in many cases.  But it makes
> IMHO the history somewhat confusing, and has limitations.  Let's say I
> had a patch against ORIG2, and at a later date I find a successor for
> it, based on GIT2.  I would not have an incarnation of GIT2 with ORIG2
> as ancestor: to be on the safe side I would have had to duplicate the
> whole GIT1..* history.

You could still branch from GIT2, cherry picking from the patch to ORIG2, and then committing the successor based on GIT2, thus reinstating the hypothetical history.

Note: the history may be confusing, but ask any history teacher: history 
*is* confusing! It is all about people. If you want to make it less 
confusing, I am afraid you have to leave the path of true history.

Show 5 quoted lines

> And after I have done some work on my branch of duplicate commits, if
> I used the type of unifying merges you suggest, I'm stuck forever with
> the old GIT1..GIT_HEAD line, whether I need it or not (if it comes
> from import of 2.4 patches, and thus has no signed tags whatsoever, I
> do not need it any more).

But the GIT1..GIT_HEAD line was actually the correct history! Remember: He who forgets his past is doomed to repeat his mistakes! Don't pretend that the past was different than it was. It's not worth the hassle.

Ciao, Dscho