The coolest merge EVER!

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