Re: 2.6.12-rc3-mm1

Ed Tomlinson
2005-04-30T22:53:52Z

On Saturday 30 April 2005 18:36, Zwane Mwaikambo wrote:
> On Sat, 30 Apr 2005, Ed Tomlinson wrote:
>
> > If we stick with git it might make sense not to include a linux-patch. cogito
> > is quite fast to export using a commit id. Suspect some bandwidth could be
> > saved if you just stated the commit id that you based the mm patch on.
> >
> > In case anyone is wondering how build this from a cogito/git db... Find the
> > cogito announcement on lkml install and update cogito. Then folliw the instructions
> > in the README and download the kernel's db. Next search lkml to find the commit id
> > of rc3 (a2755a80f40e5794ddc20e00f781af9d6320fafb) and verify you have it correct
> > with:
> >
> > cg-mkpatch a2755a80f40e5794ddc20e00f781af9d6320fafb
> >
> > then export a tree with
> >
> > cg-export ../12-3-1 a2755a80f40e5794ddc20e00f781af9d6320fafb
> >
> > and cd over to the new dir and patch with mm and have fun.
>
> That'd be a horribly convoluted procedure and make automation difficult,
> -mm shouldn't be that difficult to use. Also linus.patch used to be the
> current -bk snapshot.

Huh? Assuming one already has a current git tree. Then all Andrew need do
is publish the commit id from Linus then the complicated procedure becomes

cd <checkedout git copy of kernel>
cg-update origin
cg-export ../<work dir> <commit id>
cd ../<work dir>
cp ../<default config> .config
bzcat ../<mm patch> | patch -p1
make oldconfig
make

No problem to script this at all. Also, I suspect what when tagging starts to be
used, that <commit id> will be an easily typeable string.

With bk there was an acceptable excuse not to use it. With git, aside from bandwidth
concerns (maybe mercurial can solve this), I do not see any good reason not to use it.

Ed Tomlinson