title: Bringing two different git repositories together without losing either history
body: <p>In my current project I am facing an interesting problem with git:</p>
  
  <p>Since the beginning of the project changes were stored in a SVN repository on a remote server at my client. In the progress of development I started to have a local git repository in parallel to make it easier for me to test new features without breaking the current version. Sadly git-svn failed to work which would have make my life easier.</p>
  
  <p>Now my client switch to another server and in this process they moved the SVN repo to git (using git2svn).</p>
  
  <p>Although I'm happy about this in general, <strong>I have two problems now</strong>:</p>
  
  <ol>
  <li><p>Since I worked on a bigger feature I didn't commit to SVN for 7 days. I worked in a local feature branch and made backups of that to my local server but the SVN copy which is now the remote git repo is outdated compared to my local version.</p></li>
  <li><p>Since the remote repo has been created by git2svn it is totally different from my own repo (message: Warning: Repo has no common commits.) - which makes standard merging impossible.</p></li>
  </ol>
  
  <p>Now my <strong>desired goals</strong>:</p>
  
  <ol>
  <li><p>Merge both repos to have my current version be the checked in one and push to origin works again.</p></li>
  <li><p>Keep the history of both repos (old ones from SVN as well as the ones from the last 7 days from my git)</p></li>
  </ol>
  
  <p><strong>What I tried so far</strong>:</p>
  
  <p>I tried to clone the remote git (from svn) and merged my local repo into it. I got 153 conflicts with "changed in both versions". Accepting "theirs" (i.e. my latest developments) loses the history of the file (it just starts with the initialisation with my parallel git repo).</p>
  
  <p>My idea is that I can create a patch for each commit of the last 7 days and commit this into the new repo with the corresponding commit message (i.e. "manual merge"). Before I write a script to do this, I wanted to ask if there is a built-in way to do that.</p>
  
  <p>Thanks in advance!</p>
  
  <p><strong>UPDATE</strong>: I tried many solutions but every one of them failed me. The basic problem is that I have two branches now with <em>not a single common commit</em> but the <em>same tree structure</em>. This results in merge conflicts like "added in both branches" because git doesn't know that <code>myFile.txt" and</code>myFile.txt" are the same and can be merged. Instead I have to do a manual merge of the 150 files which I changed in that week - which I can't and won't do.</p>
  
  <p>My best approach so far was to create a patch for the changes and apply that to the "new" repo. But I didn't get around to create a patch that won't fail yet due to a tree mismatch. I have yet to find the right commit to start the patch info from.</p>
  
  <h2>Resolution</h2>
  
  <p>TL;DR: There is none. You can just choose between the lesser evil.</p>
  
  <ol>
  <li><p>You can use the <a href="https://stackoverflow.com/a/13289318/409349">merge method desribed here</a> but it will replace the individual file history from the SVN with the one from your side-git (i.e. you can't lookup why this file has been changed 3 month ago if your other repo is just 2 months old). But on the positive side you still have your changes merged together in the global history via git log.</p></li>
  <li><p>The other option I ended up with was to copy and replace all the files in the "new" (aka SVN) repo with the current status of my git repo (via <code>cp -vru</code> but omitting the <code>.git</code>-folder and all generated files). This let me loose the history worth of one week but still let me look back into the past until the beginning of the project which I prefer.
  To ease the pain of this loss a bit I crafted a detailed summary of my doings in the commit message using <code>git log --date=short --pretty="format:%cd - %s" --name-status</code> which at least gives me the chance to go back to this entry and see a message with a description.
  But of course this won't work for file deletions and you can't know which change actually belongs to which part of the biiiig commit message.</p></li>
  </ol>