From: Kyle Meyer <kyle@kyleam.com>
Date: Sat, 14 Dec 2019 23:00:38 GMT
Subject: Re: Stash does not save rename information
Message-ID: <87immizf55.fsf@kyleam.com>
In-Reply-To: <296B296B-EBA0-4F1E-AFEA-ADC232E84656@sixfeetup.com>

Chrissy Wainwright <chrissy@sixfeetup.com> 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@sigill.intra.peff.net/