title: Git rebase leaves uncommited files between steps?
body: <pre><code>&gt;git rebase &lt;parent&gt;
  First, rewinding head to replay your work on top of it...
  Applying: &lt;First Change&gt;
  Applying: &lt;Second Change&gt;
  .git/rebase-apply/patch:20: trailing whitespace.
  
  warning: 1 line adds whitespace errors.
  error: Your local changes to the following files would be overwritten by merge:
          &lt;some exiting project file file&gt;
          &lt;another existing project file&gt;
  Please commit your changes or stash them before you merge.
  Aborting
  error: Failed to merge in the changes.
  Using index info to reconstruct a base tree...
  Falling back to patching base and 3-way merge...
  Patch failed at 0002 &lt;Second change&gt;
  The copy of the patch that failed is found in: .git/rebase-apply/patch
  </code></pre>
  
  <p>I'm used to resolving <code>CONFLICT</code> files during merge or rebase. But this situation has me puzzled. There is no CONFLICT, is just that second change cannot be applied because there are files that would be overwritten, which makes no sense to me. These are all existing files which are tracked.  <code>git status</code> before the rebase shows no pending adds, the files show themselves correctly in <code>git log -- &lt;some exiting project file file&gt;</code>. The <code>&lt;First Change&gt;</code> does not touch these files. The <code>&lt;Second Change&gt;</code> modifies them, but rebase somehow sees the patch as an overwrite.</p>
  
  <p>Any explanation for this mystery, any suggestion how to tackle this problem?</p>
  
  <p><code>git version 2.14.1.windows.1</code></p>