Re: [PATCH 0/2] apply.c: a fix and an enhancement

[Ryan Anderson <ryan@michonline.com>]

On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
> 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".

hmm, I may have been a bit too terse.

Each new commit would have at least two parents:
	The commit from the current, 2.6.12-rc2 based tree.
	The commits generated by this process that have, as one of their
	children, the parents of the current commit from the 2.6.12-rc2
	based tree.

That will mean all the merge tools will find a common base, and, at
worst, cycle through an extra commit that should add *no* extra issues.

Let me see if I can draw a picture of 5 or 6 commit tree:

Today:

A0->->-A1->->-A2
 \           /
  \--B1->->-/


Stiched together:

  A0->->-A1->->-A2
  |\      |    / |
  | \--B1->->-/  |
  |    |  |      |
O-M0->->-M1->->->M2
   \   |        /
    \--N1->->->/

O being the old tree we're grafting on.

So, M0 would have parents of A0 and O, and the commit metadata from A0
N1 would have parents of M0 and B1, and the commit metadata from B1
M1 would have parents of A1 and M0, and the commit metadata from A1
M2 would have parents of A2, M1, and N1 and the commit metadata from A2

Does that help?

-- 

Ryan Anderson
  sometimes Pug Majere