From: Junio C Hamano <junkio@cox.net>
Date: Fri, 22 Jul 2005 19:46:36 GMT
Subject: Re: [PATCH 0/2] apply.c: a fix and an enhancement
Message-ID: <7vsly6vd2b.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20050722181800.GU20369@mythryan2.michonline.com>

Ryan Anderson <ryan@michonline.com> writes:

> On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
>> Now if we had a mechanism to graft a later history which starts
>> at 2.6.12-rc2 on top of this earlier history leading up to
>> it,...  ;-)
>
> We do - it's not even very hard, we just end up with 2 commits for every
> change/merge that's unique to git, until we get to the current head:

Aren't you essentially rewriting the history after 2.6.12-rc2?.
I suspect that would invalidate the current linux-2.6 history
people have been basing their work on since 2.6.12-rc2, which is
unacceptable.  That is not what I meant by "grafting".

What I meant was to give a hint to the core that says "this
2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
as not having a parent, but please consider it the same as this
other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
traversing the commit ancestry chain".

If git-rev-list is taught about that, then you will see "git
log" going across 2.6.12-rc2.  If git-merge-base is taught about
that, it will be able to find a merge base to merge a line of
development that is forked from say 2.6.11 to the current tip of
linux-2.6 tree.