From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Anderson Subject: Re: [PATCH 0/2] apply.c: a fix and an enhancement Date: Fri, 22 Jul 2005 16:16:06 -0400 Message-ID: <20050722201606.GV20369@mythryan2.michonline.com> References: <7vzmsewzik.fsf@assigned-by-dhcp.cox.net> <20050722181800.GU20369@mythryan2.michonline.com> <7vsly6vd2b.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ryan Anderson , git@vger.kernel.org, Linus Torvalds X-From: git-owner@vger.kernel.org Fri Jul 22 22:21:10 2005 Return-path: Received: from vger.kernel.org ([12.107.209.244]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dw40Y-0007qz-Pq for gcvg-git@gmane.org; Fri, 22 Jul 2005 22:20:35 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262156AbVGVUSB (ORCPT ); Fri, 22 Jul 2005 16:18:01 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262162AbVGVUSA (ORCPT ); Fri, 22 Jul 2005 16:18:00 -0400 Received: from mail.autoweb.net ([198.172.237.26]:20129 "EHLO mail.autoweb.net") by vger.kernel.org with ESMTP id S262156AbVGVUQJ (ORCPT ); Fri, 22 Jul 2005 16:16:09 -0400 Received: from pcp01184054pcs.strl301.mi.comcast.net ([68.60.186.73] helo=michonline.com) by mail.autoweb.net with esmtp (Exim 4.44) id 1Dw3wF-00029Y-Ij; Fri, 22 Jul 2005 16:16:07 -0400 Received: from mythical ([10.254.251.11] ident=Debian-exim) by michonline.com with esmtp (Exim 3.35 #1 (Debian)) id 1Dw44W-0000yz-00; Fri, 22 Jul 2005 16:24:40 -0400 Received: from ryan by mythical with local (Exim 4.52) id 1Dw3wE-0005Ve-QU; Fri, 22 Jul 2005 16:16:06 -0400 To: Junio C Hamano Content-Disposition: inline In-Reply-To: <7vsly6vd2b.fsf@assigned-by-dhcp.cox.net> User-Agent: Mutt/1.5.6+20040907i Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote: > Ryan Anderson 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