How to import existing Git repository into another?
I have a Git repository in a folder called XXX, and I have second Git repository called YYY.
I want to import the XXX repository into the YYY repository as a subdirectory named ZZZ and add all XXX's change history to YYY.
Folder structure before:
├── XXX
│ ├── .git
│ └── (project files)
└── YYY
├── .git
└── (project files)
Folder structure after:
YYY
├── .git <-- This now contains the change history from XXX
├── ZZZ <-- This was originally XXX
│ └── (project files)
└── (project files)
Can this be done, or must I resort to using sub-modules?
Solution 1:
Probably the simplest way would be to pull the XXX stuff into a branch in YYY and then merge it into master:
In YYY:
git remote add other /path/to/XXX
git fetch other
git checkout -b ZZZ other/master
mkdir ZZZ
git mv stuff ZZZ/stuff # repeat as necessary for each file/dir
git commit -m "Moved stuff to ZZZ"
git checkout master
git merge ZZZ --allow-unrelated-histories # should add ZZZ/ to master
git commit
git remote rm other
git branch -d ZZZ # to get rid of the extra branch before pushing
git push # if you have a remote, that is
I actually just tried this with a couple of my repos and it works. Unlike Jörg's answer it won't let you continue to use the other repo, but I don't think you specified that anyway.
Note: Since this was originally written in 2009, git has added the subtree merge mentioned in the answer below. I would probably use that method today, although of course this method does still work.
Solution 2:
If you want to retain the exact commit history of the second repository and therefore also retain the ability to easily merge upstream changes in the future then here is the method you want. It results in unmodified history of the subtree being imported into your repo plus one merge commit to move the merged repository to the subdirectory.
git remote add XXX_remote <path-or-url-to-XXX-repo>
git fetch XXX_remote
git merge -s ours --no-commit --allow-unrelated-histories XXX_remote/master
git read-tree --prefix=ZZZ/ -u XXX_remote/master
git commit -m "Imported XXX as a subtree."
You can track upstream changes like so:
git pull -s subtree XXX_remote master
Git figures out on its own where the roots are before doing the merge, so you don't need to specify the prefix on subsequent merges.
The downside is that in the merged history the files are unprefixed (not in a subdirectory). As a result git log ZZZ/a
will show you all the changes (if any) except those in the merged history. You can do:
git log --follow -- a
but that won't show the changes other then in the merged history.
In other words, if you don't change ZZZ
's files in repository XXX
, then you need to specify --follow
and an unprefixed path. If you change them in both repositories, then you have 2 commands, none of which shows all the changes.
Git versions before 2.9: You don’t need to pass the --allow-unrelated-histories
option to git merge
.
The method in the other answer that uses read-tree
and skips the merge -s ours
step is effectively no different than copying the files with cp and committing the result.
Original source was from github's "Subtree Merge" help article. And another useful link.
Solution 3:
git-subtree
is a script designed for exactly this use case of merging multiple repositories into one while preserving history (and/or splitting history of subtrees, though that seems to be irrelevant to this question). It is distributed as part of the git tree since release 1.7.11.
To merge a repository <repo>
at revision <rev>
as subdirectory <prefix>
, use git subtree add
as follows:
git subtree add -P <prefix> <repo> <rev>
git-subtree implements the subtree merge strategy in a more user friendly manner.
For your case, inside repository YYY, you would run:
git subtree add -P ZZZ /path/to/XXX.git master
The downside is that in the merged history the files are unprefixed (not in a subdirectory). As a result git log ZZZ/a
will show you all the changes (if any) except those in the merged history. You can do:
git log --follow -- a
but that won't show the changes other then in the merged history.
In other words, if you don't change ZZZ
's files in repository XXX
, then you need to specify --follow
and an unprefixed path. If you change them in both repositories, then you have 2 commands, none of which shows all the changes.
More on it here.
Solution 4:
There is a well-known instance of this in the Git repository itself, which is collectively known in the Git community as "the coolest merge ever" (after the subject line Linus Torvalds used in the e-mail to the Git mailinglist which describes this merge). In this case, the gitk
Git GUI which now is part of Git proper, actually used to be a separate project. Linus managed to merge that repository into the Git repository in a way that
- it appears in the Git repository as if it had always been developed as part of Git,
- all the history is kept intact and
- it can still be developed independently in its old repository, with changes simply being
git pull
ed.
The e-mail contains the steps needed to reproduce, but it is not for the faint of heart: first, Linus wrote Git, so he probably knows a bit more about it than you or me, and second, this was almost 5 years ago and Git has improved considerably since then, so maybe it is now much easier.
In particular, I guess nowadays one would use a gitk submodule, in that specific case.