Re: Kernel headers git tree

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jul 14, 2006, 17:51 UTC
Message-ID: <Pine.LNX.4.64.0607141256170.9789@iabervon.org>
In-Reply-To: <Pine.LNX.4.64.0607140843570.5623@g5.osdl.org>

On Fri, 14 Jul 2006, Linus Torvalds wrote:

Show 30 quoted lines

> On Fri, 14 Jul 2006, David Woodhouse wrote:
> 
> > On Thu, 2006-07-13 at 22:16 -0700, Linus Torvalds wrote:
> > > 
> > >         HEAD  ->     A
> > >                     / \
> > >                    B   C
> > >                   / \   \
> > >                  D   E   F
> > >                   \ /   / \
> > >                    G   H  I
> > >                   .......
> > > 
> > 
> > So working from your example above, and assuming that only commits I and
> > E actually change the files we care about. This means that merges A, B
> > and F are _also_ going to show up in the output of 'rev-list -- myfile'.
> 
> Not necessarily.
> 
> > So the slave tree will look like this:
> > 
> >         A'
> >        / \
> >       B'  F'
> >       |   |
> >       E'  I'
> 
> Yes, but ONLY IF the following is true: A is different from _both_ F and B 
> in the relevant files.

Actually, this is an unlikely result, because B' and F' wouldn't appear unless they either have multiple children that appear or they have new modifications made to the files during the merge.

The result under the conditions that the only changes are in E and I is:

   A'
  / \
 E'  I'

Which, of course, is what you should expect: it only includes E, I, and merges which create a novel combination of changes (even if the changes they include have appeared alone before).

Show 10 quoted lines

> NOTE NOTE NOTE! This is how "git rev-list" (and all the other related git 
> tools, like "git log" etc) simplify the tree. It is, in my opinion, the 
> only sane way to do it, although you can pass in "--full-history" to say 
> that you don't want any merge simplification at all.
> 
> The reason I mention it is that _your_ simplifications may obviously do 
> something else entirely, and you may obviously have different rules for 
> how you simplify the tree further. But it sounds like you don't simplify 
> the history at all (apart from the simplification that git-rev-list did 
> for you)?

It seems like we ought to be able to provide the simplification procedure to code that's done further filtering on the set of commits somehow, or provide a framework with a callback, but it's a non-trivial design.

I think that a program to generate a slave git tree based in some user-modifiable way on a parent repository would be useful and implementable. I'd thought a bunch about it a while ago, for extracting separable parts of projects (e.g., make a kbuild project that's pulled out of the kernel tree, but is still a regular git project to anyone who doesn't know this). My conclusion was that you need a cache of mappings, because otherwise you can't identify that you already have a transformed version of a commit, because you don't know its transformed parents, unless you've gone all the way back to the root (which doesn't have parents). But I think a "git2git" script wouldn't be any harder than the other import scripts, and would solve this problem nicely.

	-Daniel
*This .sig left intentionally blank*