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 

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

        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>
        commit-tree <result-tree> -p <head-tree> -p <merge-with-tree>

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

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to