# Merging two projects

2 messages from 2008-11-04 to 2008-11-04. Participants: Andrew Arnott, Jeff King.
Thread: https://gitlist.dev/t/16161

## Andrew Arnott, 2008-11-04 03:33

Subject: Merging two projects
Message-ID: <216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com>
URL: https://gitlist.dev/e/216e54900811031933n346e8c68se9226e79366c3eb6%40mail.gmail.com

```
I have two projects, both with histories, that I want to merge into
just one library.  I'd like to preserve both histories, perhaps as if
there were two branches being merged into one.  (Although each project
has its own branches that will make the history interesting).

Is there a standard way to do this?

Thanks.

```

## Jeff King, 2008-11-04 04:56

Subject: Re: Merging two projects
Message-ID: <20081104045644.GC31276@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20081104045644.GC31276%40coredump.intra.peff.net
In-Reply-To: <216e54900811031933n346e8c68se9226e79366c3eb6@mail.gmail.com>

```
On Mon, Nov 03, 2008 at 07:33:21PM -0800, Andrew Arnott wrote:

> I have two projects, both with histories, that I want to merge into
> just one library.  I'd like to preserve both histories, perhaps as if
> there were two branches being merged into one.  (Although each project
> has its own branches that will make the history interesting).
> 
> Is there a standard way to do this?

You have two options:

 - just merge the history as if they were two branches:

     # make a new combined repo
     mkdir merged && cd merged && git init

     # pull in each library
     for lib in lib1 lib2; do
       git fetch /path/to/$lib master:$lib
       git checkout $lib
       # do any pre-merging fixups
       mkdir $lib
       mv * $lib
       git add -u
       git add $lib
       git commit -m "move files into $lib in preparation for project merge"
     done

     # and then merge; order isn't really important
     git checkout lib1
     git merge lib2

   This method is nice because it preserves the original histories, and
   you can still merge from the original projects (if people are still
   working on them as individual projects).

   Note that this is basically what the subtree merge strategy does, so
   you could also use that. I showed all the steps here to give a sense
   of what is going on, and because you might want to do additional
   fixups besides moving files into the subtree.

 - The other alternative is rewriting the history. The advantage here
   is that the history looks as if the projects had always been part of
   the repo, so there is no big rename event. You can even annotate the
   commit messages to indicate which project is being worked on.

   The downside, of course, is that having rewritten history, merges
   with the original project become more difficult. But that is not a
   problem if you are going to throw away the original repositories.

   You can accomplish this with filter-branch:

     mkdir merged && cd merged && git init
     for lib in lib1 lib2; do
       git fetch /path/to/$lib master:$lib
       git checkout $lib
       git filter-branch -f \
         --index-filter '
             git ls-files -s |
             sed "s,\t,&'$lib'/," |
             GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
               git update-index --index-info &&
               mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' \
         --msg-filter "sed '1s/^/[$lib] /'" \
         $lib
     done

   and then merge the resulting branches as usual.

Hope that helps.

-Peff

```