On Mon, Dec 05, 2016 at 09:37:51AM -0500, Matthew Patey wrote: > Git version 2.8.0 (sorry can't update to more recent on my machine) on Ubuntu. The behavior is the same on more recent versions of git, too. The short answer is "use --index". The longer one is below. > After moving a file, if the new file is in the index but the deletion > of the old file is not staged, git stash loses the deletion operation. > Repro: > > 1. git mv a b > This will have both the "deletion" and the "file added" in the index > > 2. git stash; git stash pop > Now file a is still in the index, but file b deletion is not staged. > > 3. git stash; git stash show -v > This will show that the deletion operation is not in the stash > > 4. git stash pop > Again confirms the issue, file a is in the index, but file b is > present and unmodified in the working directory. Thanks for a clear reproduction case. I think the oddball, though, is not that "b" is not staged for deletion, but that the addition of "a" _is_ staged. Applying a stash usually does not re-stage index contents, unless you specify --index. For example, try: # Make a staged change echo change >>a git add a # This puts the change back into the working tree, but does _not_ # put it into the index. git stash apply # Now reset to try again. git reset --hard # This does restore the index. git stash apply --index So in your case, the deletion of "b" is following that same rule. What's unusual is that "a" is staged. There's code specifically in git-stash specifically to make sure this is the case, but I don't remember offhand why this is so. The code comes from the original f2c66ed19 (Add git-stash script, 2007-06-30), which in turn seems to come from Junio's comments in: http://public-inbox.org/git/7vmyyq2zrz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx/ I don't see any specific reasoning, but I think it is simply that it is confusing for the files to become untracked totally. These days we have intent-to-add via "git add -N", so that might actually be a better choice for this case. Anyway, that history digression is neither here nor there for your case. If you want to restore the index contents, use "--index". That does what you were expecting: $ git mv a b $ git stash && git stash apply --index Saved working directory and index state WIP on master: 5355755 foo HEAD is now at 5355755 foo On branch master Changes to be committed: renamed: a -> b -Peff