Re: Joining Repositories

Linus Torvalds wrote:
> 
> On Wed, 18 Jan 2006, Ryan Anderson wrote:
> 
>>Assuming both repositories are clean, no extraneous files, and without
>>testing, of course:
>>
>>In r1:
>>	mkdir r1
>>	# move everything into the subdirectory called r1.
>>	git mv $(ls -a | grep -v -e ^.git$ -e ^r1$) r1/
>>	git commit -a "Restructure directory"
>>
>>In r2:
>>	mkdir r2
>>	# move all files into r2/
>>	git mv $(ls -a | grep -v -e ^.git$ -e ^r2$) r2/
>>	git commit -a "Restructure directory"
>>
>>	git fetch ../r1/
>>	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
>>
>>No history rewritten,
> 
> 
> Right.
> 
> 
>>merging with the old repositories should, at least theoretically, work, 
>>etc.
> 
> 
> No. This - and the history rewriting - both have a fundamental problem: it 
> becomes totally impossible to merge back any changes of the subprojects, 
> at least automatically. The renaming just ends up making pretty much any 
> merge a manual affair (git can _help_, but it's going to be a matter of 
> luck if it works or not - and it usually won't work very well, because 
> you'll probably end up having files that have the same name in the new and 
> the old repo, and eventually you'll just have tons of confusion).

What I meant was that an old repository can continue to be developed in,
and, in theory, the recursive merge should be able to merge those
changes into this new, joined, repository.



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