Re: Stash does not save rename information
- From
Kyle Meyer <kyle@kyleam.com>
- Date
- Dec 14, 2019, 23:00 UTC
- Message-ID
- <87immizf55.fsf@kyleam.com>
- In-Reply-To
- <296B296B-EBA0-4F1E-AFEA-ADC232E84656@sixfeetup.com>
Chrissy Wainwright <chrissy@sixfeetup.com> writes:
Show 7 quoted lines
> 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: foono 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@sigill.intra.peff.net/