Re-done kernel archive - real one?

Ok, nobody really objected to the notion of leaving the kernel history behind for now, and in fact most people seemed to basically agree. So with that decided, the old kernel testing tree was actually perfectly ok, except it had been build up with the old-style commit date handling, which made me not want to use it as a base for any real work.

So I re-created the dang thing (hey, it takes just a few minutes), and pushed it out, and there's now an archive on kernel.org in my public "personal" directory called "linux-2.6.git". I'll continue the tradition of naming git-archive directories as "*.git", since that really ends up being the ".git" directory for the checked-out thing.

I'm not going to announce it on linux-kernel yet, because I don't think it's useful to anybody but a git person anyway. Besides, I don't actually know how happy the kernel.org people are about this distribution method and whether it ends up being a horrible disaster for the mirroring setup.

Peter made some noises about /pub/scm, which makes sense, and would be a better place than my public tree. Apparently there are other places that are willing and able to host things too, so we'll see.

NOTE! The roughly 10x expansion of archive size goind from BK to git ends up in a similar 10x bandwidth expansion, in addition to just the overhead of reading tons of directory entries and comparing them (which is what both a wget and rsync thing ends up doing). I'm sure we can bring that down with smarter synchronization tools, but I also suspect that's some way away.

So is real common usage, though, so maybe it's not that bad at all. Who knows. We haven't hit a single real snag so far (except it took several days longer than I expected, but hey, I expect lots of things ;), and I'm sure real usage will show lots of them.

Similarly, we don't really have real merging, which makes tracking harder, but I suspect actually having a tree out there will make people more motivated and have more of a test-case. I'm feeling good enough about the plumbing that I think I solved the "hard" part of it, and now it's just the boring 95% left - scripting around it.

I think that with the new merge model, the easiest thing to do is to just download all new objects, and then download the HEAD file under a new name.

Ie we have two phases to the merge: first get the objects, with something like

	repo=kernel.org:/pub/kernel/people/torvalds/linux-2.6.git
	rsync --ignore-existing -acv $(repo)/ .git/

which will _not_ download the new HEAD file (since you already have one of your own), and then when you actually decide to merge you do

	rsync -acv $(repo)/HEAD .git/MERGE_WITH

and now you can look at your old HEAD, and the MERGE_WITH thing, look up the parents, and then do

	read-tree -m <parent-tree> <head-tree> <merge-with-tree>
	write-tree
	commit-tree <result-tree> -p <head-tree> -p <merge-with-tree>

(which should actually _work_, assuming that the merge had no file conflicts).

This seems to be a sane way to do merges, and if the scripting starts from there and then becomes smarter...

		Linus