Git: merging two diverged, independent repos

Repository A: migrated to git from a project's SVN at revision r: cloned the whole thing including all of SVN's history, tags, etc. A little development on git afterwards.

Repository B: the same project, but independently migrated from SVN at revision r+small_number. Only the latest snapshot was brought into git. Lots of independent development afterwards.

Now I merged A into B. The idea is that SVN will be discarded, development will continue in the develop开发者_如何学编程 branch of the project's repo on GitHub. I used simple merge to do the job; thankfully there were very few real conflicts. The development was mostly in different areas, though there was a lot of cleaning up after the merge, unrelated to git.

But: now when I do e.g. git rebase -i HEAD~2 on the merged result, which I understand should let me rebase the last two commits, I am greeted with a page of some 300+ commits -- the complete history of the project since revision 1 in SVN. I aborted the rebase for fear of messing up even more (obviously I'm a complete Git novice).

Is that outcome expected? Is it desirable? If not, how to fix it?

Note that all unit tests etc. pass, the files themselves are ok, only I don't understand what happened to git metadata/history.

EDIT: this is what I *think* the repository looks like now:

          r         A
... o --- o --- ... o 
                     \ 
               B      \    
    o --- .... o ----  o --- ... o 
   r+small_number      C         HEAD

---

I guess this behaviour occurs because you are trying to rebase over a merge commit.

For the following answer, I'm assuming that your history looks like this, i.e. repositories A and B are completely independent:

          r         A
... o --- o --- ... o

o ... o
r'    B

You need to ask yourself what are you trying to achieve? So you want to have a new branch C containing both the changes in A and B. What are the priorities here? Do you want to achieve a proper history; correcting the fact that r' lost its SVN history? Or is it important to keep the git history of A and B unchanged?

My answer is going to assume you want to achieve the former. As both A and B descendet from very similar versions of the SVN repository, it might be a good idea to give them a common git base before merging the common history. So, ideally before merging you would have the situation:

          r          A
... o --- o --- .... o
           \
            \
             o --- .... o
       r+small_number   B

At the moment, I'm not sure which is the best way to achieve this, but you could try doing git rebase -p --onto r --root B.

Then you could just git merge A and B and end up with the history

          r          A     C
... o --- o --- .... o --- o
           \              /
            \            /
             o --- .... o
       r+small_number   B

where C contains all your changes. I would probably leave it at that; without any further rebasing.