* Re: Stash does not save rename information
2019-12-16 14:32 ` Chrissy Wainwright
@ 2019-12-16 18:42 ` Bryan Turner
2019-12-16 19:25 ` Jeff King
1 sibling, 0 replies; 6+ messages in thread
From: Bryan Turner @ 2019-12-16 18:42 UTC (permalink / raw)
To: Chrissy Wainwright; +Cc: Kyle Meyer, git
On Mon, Dec 16, 2019 at 6:32 AM Chrissy Wainwright
<chrissy@sixfeetup.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Stash does not save rename information
2019-12-16 14:32 ` Chrissy Wainwright
2019-12-16 18:42 ` Bryan Turner
@ 2019-12-16 19:25 ` Jeff King
1 sibling, 0 replies; 6+ messages in thread
From: Jeff King @ 2019-12-16 19:25 UTC (permalink / raw)
To: Chrissy Wainwright; +Cc: Kyle Meyer, git
On Mon, Dec 16, 2019 at 02:32:31PM +0000, Chrissy Wainwright 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.
I think this is a spot where git-stash could be a little friendlier. If
you've stashed index changes and "git stash pop", then those index
changes are not applied but get thrown away, losing information.
It would be nicer if "stash pop" noticed that there are entries in the
stashed index that do not match HEAD or the stashed working tree, and
applied as requested but _didn't_ remove the stash (with a message that
you can get your index changes out with "--keep-index").
Maybe a good small project for somebody looking to get their feet wet
with contributing to Git (you, or anybody else reading this).
-Peff
^ permalink raw reply [flat|nested] 6+ messages in thread