{"thread":{"id":"16161","subject":"Merging two projects","startedAt":"2008-11-04T03:33:21Z","lastAt":"2008-11-04T04:56:44Z","messageCount":2,"participants":["Andrew Arnott","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94842","messageId":"216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com","threadId":"16161","inReplyTo":null,"subject":"Merging two projects","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-11-04T03:33:21Z","receivedAt":"2008-11-04T03:33:21Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"I have two projects, both with histories, that I want to merge into\njust one library.  I'd like to preserve both histories, perhaps as if\nthere were two branches being merged into one.  (Although each project\nhas its own branches that will make the history interesting).\n\nIs there a standard way to do this?\n\nThanks.\n"},{"id":"94850","messageId":"20081104045644.GC31276@coredump.intra.peff.net","threadId":"16161","inReplyTo":"216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com","subject":"Re: Merging two projects","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-11-04T04:56:44Z","receivedAt":"2008-11-04T04:56:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 03, 2008 at 07:33:21PM -0800, Andrew Arnott wrote:\n\n> I have two projects, both with histories, that I want to merge into\n> just one library.  I'd like to preserve both histories, perhaps as if\n> there were two branches being merged into one.  (Although each project\n> has its own branches that will make the history interesting).\n> \n> Is there a standard way to do this?\n\nYou have two options:\n\n - just merge the history as if they were two branches:\n\n     # make a new combined repo\n     mkdir merged && cd merged && git init\n\n     # pull in each library\n     for lib in lib1 lib2; do\n       git fetch /path/to/$lib master:$lib\n       git checkout $lib\n       # do any pre-merging fixups\n       mkdir $lib\n       mv * $lib\n       git add -u\n       git add $lib\n       git commit -m \"move files into $lib in preparation for project merge\"\n     done\n\n     # and then merge; order isn't really important\n     git checkout lib1\n     git merge lib2\n\n   This method is nice because it preserves the original histories, and\n   you can still merge from the original projects (if people are still\n   working on them as individual projects).\n\n   Note that this is basically what the subtree merge strategy does, so\n   you could also use that. I showed all the steps here to give a sense\n   of what is going on, and because you might want to do additional\n   fixups besides moving files into the subtree.\n\n - The other alternative is rewriting the history. The advantage here\n   is that the history looks as if the projects had always been part of\n   the repo, so there is no big rename event. You can even annotate the\n   commit messages to indicate which project is being worked on.\n\n   The downside, of course, is that having rewritten history, merges\n   with the original project become more difficult. But that is not a\n   problem if you are going to throw away the original repositories.\n\n   You can accomplish this with filter-branch:\n\n     mkdir merged && cd merged && git init\n     for lib in lib1 lib2; do\n       git fetch /path/to/$lib master:$lib\n       git checkout $lib\n       git filter-branch -f \\\n         --index-filter '\n             git ls-files -s |\n             sed \"s,\\t,&'$lib'/,\" |\n             GIT_INDEX_FILE=$GIT_INDEX_FILE.new \\\n               git update-index --index-info &&\n               mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' \\\n         --msg-filter \"sed '1s/^/[$lib] /'\" \\\n         $lib\n     done\n\n   and then merge the resulting branches as usual.\n\nHope that helps.\n\n-Peff\n"}]}