It may not be pretty, but it seems to have worked fine!
Here's my history log (with intermediate checking removed - I was being
pretty anal ;):
rsync -avz --ignore-existing
master.kernel.org:/home/rmk/linux-2.6-rmk.git/ .git/
rsync -avz --ignore-existing
master.kernel.org:/home/rmk/linux-2.6-rmk.git/HEAD .git/MERGE-HEAD
merge-base $(cat .git/HEAD) $(cat .git/MERGE-HEAD)
for i in e7905b2f22eb5d5308c9122b9c06c2d02473dd4f $(cat .git/HEAD)
$(cat .git/MERGE-HEAD); do cat-file commit $i | head -1; done
read-tree -m cf9fd295d3048cd84c65d5e1a5a6b606bf4fddc6
9c78e08d12ae8189f3bd5e03accc39e3f08e45c9
a43c4447b2edc9fb01a6369f10c1165de4494c88
write-tree
commit-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6 -p $(cat
.git/HEAD) -p $(cat .git/MERGE-HEAD)
echo 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a > .git/HEAD
fsck-cache --unreachable 5fa17ec1c56589476c7c6a2712b10c81b3d5f85a
which looks really messy, because I really wanted to do each step slowly
by hand, so those magic revision numbers are just cut-and-pasted from the
results that all the previous stages had printed out.
NOTE! As expected, this merge had absolutely zero file-level clashes,
which is why I could just do the "read-tree -m" followed by a write-tree.
But it's a real merge: I had some extra commits in my tree that were not
in Russell's tree, and obviously vice versa.
Also note! The end result is not actually written back to the corrent
working directory, so to see what the merge result actually is, there's
another final phase:
read-tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
update-cache --refresh
checkout-cache -f -a
which just updates the current working directory to the results. I'm _not_
caring about old dirty state for now - the theory was to get this thing
working first, and worry about making it nice to use later.
A second note: a real "merge" thing should notice that if the "merge-base"
output ends up being one of the inputs (it one side is a strict subset of
the other side), then the merge itself should never be done, and the
script should just update directly to which-ever is non-common HEAD.
But as far as I can tell, this really did work out correctly and 100%
according to plan. As a result, if you update to my current tree, the
top-of-tree commit should be:
cat-file commit $(cat .git/HEAD)
tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
parent 8173055926cdb8534fbaed517a792bd45aed8377
parent df4449813c900973841d0fa5a9e9bc7186956e1e
author Linus Torvalds <[EMAIL PROTECTED]> 1113774444 -0700
committer Linus Torvalds <[EMAIL PROTECTED]> 1113774444 -0700
Merge with master.kernel.org:/home/rmk/linux-2.6-rmk.git - ARM changes
First ever true git merge. Let's see if it actually works.
Yehaa! It did take basically zero time, btw. Except for my bunbling about,
and the first "rsync the objects from rmk's directory" part (which wasn't
horrible, it just wasn't instantaneous like the other phases).
Btw, to see the output, you really want to have a "git log" that sorts by
date. I had an old "gitlog.sh" that did the old recursive thing, and while
it shows the right thing, the ordering ended up making it be very
non-obvious that rmk's changes had been added recently, since they ended
up being at the very bottom.
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
