title: git cherry-pick a range of commits to prevent history breakage
body: <h1>Short description of problem</h1>
  
  <p>After a new developers group joined our project they initialized a new repo and copied (not merged!) <strong>snapshot of master</strong> into newly created repo. So in their branch old files lost history of commits which exist in <code>master</code>. After that they started typical git workflow with comitting, branching, merging updates from master etc. And now the problem is to merge their code into <code>master</code> or <code>dev</code> excluding first two commits and preserving our history (and preserving their history also would be good).</p>
  
  <h1>Detailed problem description</h1>
  
  <p>So we have branches: <code>master</code>, <code>dev</code> and <code>funny_developers</code>.</p>
  
  <p>Here is our branch structure:</p>
  
  <pre><code>I---A---B---C---D---Y...X      &lt;--(master/dev)
              \!\      \
         I'---IABC--G--DY..Z     &lt;--(funny_developers flow)
  </code></pre>
  
  <p><code>I...C...X</code> - is our main flow of developement (<code>master</code> and <code>dev</code> branches are syncronized now)  with history of commits. This flow has no imports from <code>funny_developers</code> branches</p>
  
  <p><code>I'</code> - is a commit where <code>funny_developers</code> re-initilised a new repo with empty one (seems they made <code>git-init</code>?) . </p>
  
  <p><code>IABC</code> - very dirty commit, where <code>funny_developers</code> copy all files existing in <code>master</code> at the moment of commit <code>C</code> as <strong>new files</strong>. Not merge from <code>C</code>, just recreate project's file structure! So they dropped out all history of changes made during <code>master</code> branch evolution).</p>
  
  <p><code>G..Z</code> - is a bulk of commits where they made a lot of changes. During this flow they also had merged updates from master several times, had created their own branches, had merged them into <code>funny_developers</code> (sometimes with conflict resolution), etc.</p>
  
  <p>So now I have problems with merging <code>G..Z</code> into <code>master</code> preserving our initial history of commits and their too (excluding <code>I'</code> and <code>IABC</code> commits). </p>
  
  <h1>Question</h1>
  
  <p><strong>Could you advice me the best method (if exist) to grab their commits into <code>master</code> and preserve commit history excluding first two ones?</strong></p>
  
  <h1>My experiments for saving Queen and Kingdom at once</h1>
  
  <p>I tried <code>git cherry-pick G..Z</code>. But they were coding in parallel branches and were doing a lot of merges into <code>funny_developers</code>. They resolved a lot of own-branches conflicts. It seems I need a lot of time to resolve them again if I decide to use this method.</p>
  
  <p>I tried <code>git rebase --onto master IABC Z</code>, expecting it able to move branch buckets all within <code>G..Z</code> onto <code>master</code>. But I stucked with a bunch of conflicts related to commits which was a long time ago (even before 'funny_developers' was started). And I can not understand how they relate to actual rebase (may be it because they have reinitilized repo...).</p>
  
  <p>Anyway if I find no solution preserving "both histories" I tend to make diff for all their work and provide it as single patch-commit for <code>master</code>. </p>