title: Git rebase after merge confused about deleted file
body: <p>My Git repository has two files, <code>alpha</code> and <code>beta</code>, with identical content.</p>
  
  <p>If I delete <code>alpha</code> in my master branch, and edit it in my feature branch, then when I merge master into feature, I'm warned about a conflict. Assume I resolve this by deleting <code>alpha</code>.</p>
  
  <p>If I then rebase my feature branch onto master using <code>git rebase master</code>, <code>alpha</code> is deleted, but the changes I made to <code>alpha</code> on the feature branch are now applied to <code>beta</code>! I get a conflict warning but it's happily resolved with an auto-merge without the commit being blocked for me to review.</p>
  
  <p>Interestingly, if I do a <code>git rebase -i</code> and just accept the default, <code>beta</code> isn't edited and I get to resolve the same conflict I resolved at merge time.</p>
  
  <p>Three related questions then:</p>
  
  <ol>
  <li>Why does Git think the change I applied to one file should be applied to another, when the other hasn't been edited by any commit?</li>
  <li>How can I avoid this sort of situation?</li>
  <li>Why is the behaviour different for an interactive rebase, even when I take the default options?</li>
  </ol>
  
  <p>I'm running Git 1.7.9 on Cygwin on Win7. I've put a <a href="http://pastebin.com/Lfb9jRy0">transcript on pastebin</a> showing this starting with a <code>git init</code> in an empty directory, if anyone wants to see the details for themselves (I'm not posting it here due to length).</p>