The coolest merge EVER!

[Linus Torvalds <torvalds@osdl.org>]

Ok, Junio had some cool octopus merges, but I just one-upped him.

I just merged the "gitk" repository into git, and I did it as a real git
merge, which means that I actually retained all the original gitk
repository information intact. IOW, it's not a "import the data" thing,
it's literally a merge of the two trees, and the result has two roots.

Now, the advantage of this kind of merge is that Paul's original gitk
repository is totally unaffected by it, yet because I now have his history
(and the exact same objects), the normal kind of git merge should work
fine for me to continue to import Paul's work - we have the common parent
needed to resolve all differences.

Now, I don't know how often this ends up being actually used in practice, 
but at least in theory this is a totally generic thing, where you create a 
"union" of two git trees. I did the union merge manually, but in theory it 
should be easy to automate, with simply something like

	git fetch <project-to-union-merge>
	GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
	GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
	git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
	cp .git/FETCH_HEAD .git/MERGE_HEAD
	git commit

(this is not exactly how I did it, but that's just because I'd never done
this before so I didn't think it through and I had some stupid extra steps
in between that were unnecessary).

Of course, in order for the union merge to work, the namespaces have to be
fit on top of each other with no clashes, otherwise future merges will be 
quite painful. In the case of gitk, Paul's repository only tracked that 
single file, so that wasn't a problem.

Anyway, you shouldn't notice anything new, except for the fact that "gitk" 
now gets automatically included with the base git distribution. And the 
git repository has two roots, but hey, git itself doesn't care.

			Linus