From: Ryan Anderson Date: Wed, 18 Jan 2006 18:55:50 GMT Subject: Re: Joining Repositories Message-ID: <43CE8F36.3090100@michonline.com> In-Reply-To: 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.