Re: 2.6.12-rc3-mm1

[Ed Tomlinson <tomlins@cam.org>]

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