Let\'s say I\'ve got a setup that look something like
phd/code/
phd/figures/
phd/thesis/
For historical reasons, these all have their own g
You could try the subtree merge strategy. It will let you merge repo B into repo A. The advantage over git-filter-branch
is it doesn't require you to rewrite your history of repo A (breaking SHA1 sums).
Perhaps, simply (similarly to the previous answer, but using simpler commands) making in each of the separate old repositories a commit that moves the content into a suitably named subdir, e.g.:
$ cd phd/code
$ mkdir code
# This won't work literally, because * would also match the new code/ subdir, but you understand what I mean:
$ git mv * code/
$ git commit -m "preparing the code directory for migration"
and then merging the three separate repos into one new, by doing smth like:
$ cd ../..
$ mkdir phd.all
$ cd phd.all
$ git init
$ git pull ../phd/code
...
Then you'll save your histories, but will go on with a single repo.
The sequence you suggested
git init
git add *
git commit -a -m "import everything"
will work, but you will lose your commit history.
To merge a secondProject within a mainProject:
A) In the secondProject
git fast-export --all --date-order > /tmp/secondProjectExport
B) In the mainProject:
git checkout -b secondProject
git fast-import --force < /tmp/secondProjectExport
In this branch do all heavy transformation you need to do and commit them.
C) Then back to the master and a classical merge between the two branches:
git checkout master
git merge secondProject
The git-filter-branch solution works well, but note that if your git repo comes from a SVN import it may fail with a message like:
Rewrite 422a38a0e9d2c61098b98e6c56213ac83b7bacc2 (1/42)mv: cannot stat `/home/.../wikis/nodows/.git-rewrite/t/../index.new': No such file or directory
In this case you need to exclude the initial revision from the filter-branch - i.e. change the HEAD
at the end to [SHA of 2nd revision]..HEAD
- see:
http://www.git.code-experiments.com/blog/2010/03/merging-git-repositories.html
git-stitch-repo from Aristotle Pagaltzis' answer only works for repositories with simple, linear history.
MiniQuark's answer works for all repositories, but it does not handle tags and branches.
I created a program that works the same way as MiniQuark describes, but it uses one merge commit (with N parents) and also recreates all tags and branches to point to these merge commits.
See the git-merge-repos repository for examples how to use it.