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

From: Yann Dirson <ydirson@altern.org>
Date: Nov 20, 2005, 22:32 UTC
Message-ID: <20051120223249.GI3393@nowhere.earth>
In-Reply-To: <Pine.LNX.4.63.0511200217200.11653@wbgn013.biozentrum.uni-wuerzburg.de>

On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:

Show 29 quoted lines

> Hi,
> 
> On Sat, 19 Nov 2005, Matthias Urlichs wrote:
> 
> > [...] What can you do with such a thing that you cannot do now, just as 
> > easily, besides slow down your programs with an unnecessary level of 
> > indirection?
> 
> I tend to agree. In fact, if I would like to introduce earlier history 
> (for the sake of archeology or whatever), I would import the earlier 
> history into git, possibly finding the best match in the current 
> development branch (for example, when the original project continued for a 
> while to be tracked in CVS), and then make a merge between these two.
> 
> Then, I'd merge the new development's HEAD, and it would be fine:
> 
> ORIG1 .. ORIG2 .. .. ORIG_HEAD
>                          |
>                          |   GIT1 .. GIT2 .. .. GIT_HEAD
>                          |   /                    /
>                          | /                     /
>                       UNIFYING_MERGE           /
>                                    \         /
>                                      \     /
>                                NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES
> 
> Where ORIG_HEAD's tree is identical with GIT1's tree. The resulting branch 
> would serve every research purpose I can think of (just be sure not to 
> use "-m" with git-whatchanged).

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.

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.

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).

Best regards,

-- 
Yann Dirson    <ydirson@altern.org> |
Debian-related: <dirson@debian.org> |   Support Debian GNU/Linux:
                                    |  Freedom, Power, Stability, Gratis
     http://ydirson.free.fr/        | Check <http://www.debian.org/>