title: git checkout fails due to local changes but stash applies cleanly afterwards
body: <p>It happens often that I try to checkout a new remote branch (to create a local branch out of it, but this might be irrelevant to my issue) and git fails with the following error</p>
  
  <blockquote>
    <p>error: Your local changes to the following files would be overwritten by checkout:<br>
    Please, commit your changes or stash them before you can switch branches.</p>
  </blockquote>
  
  <p>Now, when I see this, one could naively expect that if one stashes the changes, checkout the new branch and then apply the stashed changes then there would be a conflict, but that is almost never the case. What happens is that the stashed changes apply cleanly and I don't lose anything from what I had before I checked out the new branch. Why is git giving this seemingly misleading error? <strong>if I can stash before checking out and apply the stash at the end cleanly, why isn't <code>git checkout</code> doing just that under the hood?</strong></p>
  
  <p>Edit:<br>
  To make it clearer, I am not asking why the checkout fails, or why sometimes a checkout with a dirty workspace succeeds, I understand all that. My questions is that in this case there is a course of action that is 100% data-loss free (or is there some corner case where data could be lost that I fail to see??) so why doesn't git just do it? </p>
  
  <p>If I said to someone new to git that a modif on file <code>foo</code> line 100 would conflict with another modif on file <code>foo</code> line 2 it would kind of make sense to them an accept it as truth, not complain and would easily fix the conflict. But because git is a nice tool, it does the smart thing and doesn't even bother you with a non-issue that it can fix without any risks of corruption. Why is that not the same philosophy in this scenario with <code>git checkout</code>? </p>