title: Make Cherry Pick not bring in history
body: <p>So I've run into an issue with git where when I rebase or cherry pick a specific commit, I will get much more information than is in that specific commit. That issue is outlined really nicely in this question here:</p>
  
  <p><a href="https://stackoverflow.com/questions/4121631/am-i-misunderstanding-git-cherry-pick">Am I misunderstanding git cherry-pick?</a></p>
  
  <p>And that is all well and good, I understand that it is picking up history because the commit I want depends on that history being there. What I don't get is how to get around it. I really don't want cherry pick to apply all of that history, what I would much rather is for it to use that history to figure out where the lines should go and then raise a conflict saying that it had to do something fishy in order to make it fit.</p>
  
  <p>Is there any way for me to do this? The only way I have found is I can make a patch out of that commit and apply the patch, but I really want to be able to use cherry-pick and rebase for my trees. </p>
  
  <p>To illustrate my example, you can iniitalize a git repository in an empty directory then add a text file with 1 line to your repository. Then add 3 more lines to the file in 3 seperate commits, so you will have 4 commits and 4 lines in your file. My file lookes like:</p>
  
  <pre><code>line 1
  line 2
  line 3
  line 4
  </code></pre>
  
  <p>Now do git checkout HEAD~3 so that you have only</p>
  
  <pre><code>line 1
  </code></pre>
  
  <p>Then call git cherry-pick HEAD and you will get a conflict. Why this happens is outlined in the link I posted above. Your file will look like this:</p>
  
  <pre><code>line 1
  &lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
  =======
  line 2
  line 3
  line 4
  
  &gt;&gt;&gt;&gt;&gt;&gt;&gt; 6fe905b... Commit 4
  </code></pre>
  
  <p>But this is bad because if this comes up in a real example, your merge conflict is saying that Commit 4 had Much more stuff than was actually in Commit 4. So is there any way for me to fix it so that cherry-pick will give me a more logical merge conflict? In my real world issue where this is coming up, it's occuring when I am doing a rebase. If I can fix this for cherry-pick, my logic is that the underlying cause for this should be fixable for rebase as well.</p>