Re: Kernel headers git tree

[David Woodhouse <dwmw2@infradead.org>]

On Fri, 2006-07-14 at 11:01 -0700, Junio C Hamano wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
> 
> > Yet what I actually want in the final result is "those commits which
> > change the result of the _exported_ headers". It's slightly less
> > realistic to want rev-list to find that for me directly from the
> > original kernel tree without having done the export step in stage1 --
> > what I need to do is create the exported header tree for each commit
> > which _might_ change it, then filter out the commits which don't
> > _actually_ change it.
> >
> > The extra commits in the stage1 branch are cheap enough -- by definition
> > they don't lead to any extra tree or blob objects. I think the two-stage
> > export is probably the best approach, unless I'm missing something.
> 
> Since you are not building an exact parallel history with the
> same topology (you are trying to cull the commits in the new
> tree that do not change the resulting header files), I do not
> see much point in the parent conversion loop in the first script
> to compute CONVERTEDPARENTS.
> 
> How about making it simpler?
> 
> 	* Keep the current HEAD of the "headers" branch at in
>           refs/heads/kernel-headers
> 
> 	* Whenever you see $UPSTREAM_GITDIR/refs/heads/master
>           changes, you do your converttree to come up with the
>           new header tree
> 
> 	* See if the resulting tree changed by doing something
>           like this:
> 
>                 TREE=`converttree $INCDIR $KBUILDASMSHA`
>                 case "`git diff-tree --name-only kernel-headers $TREE`" in
>                 '')
>                         # No changes in the result
>                         exit
>                 esac
> 
> 	  Stop processing here if there is no change.
> 
> 	* Make a new commit, with its parent set to the current
>           value of refs/heads/kernel-headers, perhaps with the
>           same message as $UPSTREAM_GITDIR/refs/heads/master
>           has as you do already.
> 
> 	* Advance refs/heads/kernel-headers only when you
>           actually make a new commit.

Unless I'm misunderstanding, I then don't get a tree with a topology
which matches Linus' tree -- I just get a series of snapshots, and it's
dependent on the timing of my cron jobs.

That means that there isn't a 1:1 relationship between any commit in the
slave tree and a corresponding commit in the upstream tree, and that the
slave tree can't (sensibly) be reproduced.

I'd much rather keep it the way it is -- but I'm certainly interested in
ways that I could simplify the process of generating what I have at the
moment.

> I would further suggest to record the value of the upstream
> commit object name, $UPSTREAM_GITDIR/refs/heads/master,
> somewhere in the commit message, by using "git describe".  This
> will help people who use your converted headers to know which
> released version of the Linus kernel the headers correspond to,
> and also help you notice when the upstream is updated during the
> next run.

Yeah, that was already suggested. I'll do that.

-- 
dwmw2