On Mon, Dec 16, 2019 at 6:32 AM Chrissy Wainwright
<chrissy@xxxxxxxxxxxxx> wrote:
>
> Thank you, using --index does work! Now the trick is to actually remember to use it in this case, since it doesn't seem the change can be restored if you forget to use it the first time you pop/apply.
You could create a Git alias for it, if that helps.
>
> Then the fix is to `git mv` the files back to the original name, and to the new name again.
That shouldn't be necessary. Really all you need to do is stage the
parts of the change that "git stash apply" didn't automatically stage
as part of restoring them. "git add -a" would likely do it, but may
also stage other things. A simple "git add foo" (based on the names
from your example) should also do it:
$ git init foo
Initialized empty Git repository in /.../foo/.git/
$ cd foo
$ touch foo && git add foo && git commit -m "Initial commit"
[master (root-commit) 934d270] Initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo
$ git mv foo bar
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: foo -> bar
$ git stash
Saved working directory and index state WIP on master: 934d270 Initial commit
$ git stash apply
Removing foo
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: bar
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: foo
$ git add foo
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: foo -> bar
On some older versions of Git you may need to use "git add -f foo" to
add the deleted file, but at least on 2.20.1, what I happen to be
running locally, it's not necessary.
With or without "-f", all you really need to do is update what parts
of the change are staged; you don't need to (essentially) revert and
reapply the change.
One other thing I think may be worth clarifying, just in case it's not
know, is in relation to the subject: "Stash does not save rename
information." Git itself does not track renames, at all, in any
commands. git mv does not somehow record renames; it's just a
simplification for:
mv foo bar
git rm foo # or git add foo to stage the deletion
git add bar
You can confirm that easily:
$ git reset --hard HEAD
HEAD is now at 934d270 Initial commit
$ mv foo bar
$ git rm foo
rm 'foo'
$ git add bar
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: foo -> bar
$ git reset --hard HEAD
HEAD is now at 934d270 Initial commit
Lafiel:foo bturner$ mv foo bar
Lafiel:foo bturner$ git add foo bar
Lafiel:foo bturner$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: foo -> bar
Git uses heuristics to "pair up" deletions and adds into probable
renames. If you rename a file and change it significantly as part of
the same commit, Git will not consider it a rename. Similarly, if you
rename multiple similar files in a single commit, paired with some
changes to those files, Git may pair up the "wrong" combinations (i.e.
if you rename A to X and B to Y, "git diff" may show renaming A to Y
and B to X).
Hope this helps,
Bryan Turner
>
> Thanks
> Chrissy Wainwright
