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
-
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
