On Fri, 2006-07-14 at 11:01 -0700, Junio C Hamano wrote: > David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html