Chrissy Wainwright <chrissy@xxxxxxxxxxxxx> writes:
> This seems to be a bug:
>
> 1 Use `git mv` to rename a file
> 2 `git status` shows the file was renamed
> 3 Stash the changes
> 4 Pop the stash
> 5 `git status` shows the file change as deleted/new file instead of a rename
You can see very similar behavior with just a deleted file rather than a
deleted/new file pair (which is displayed as a rename depending on your
configuration):
$ git init
$ touch foo && git add foo && git commit -mfoo
$ git stash
$ git stash apply
Removing foo
On branch master
Changes not staged for commit:
deleted: foo
no changes added to commit
I believe the key thing is that by default 'git stash {apply,pop}' will
apply your change to the working tree but not the index [*]. If you
pass the --index flag, you should see the behavior you're after:
$ git reset --hard
HEAD is now at c023af6 foo
$ git stash apply --index
Removing foo
On branch master
Changes to be committed:
deleted: foo
[*] When I initially tried your example, I was confused that the new
file was added to the index by default, but it seems new files
receive special treatment, as Jeff King mentions at
https://lore.kernel.org/git/20161206142446.5ba3wc625p5o6nct@xxxxxxxxxxxxxxxxxxxxx/
