Deleted files are being restored to the working tree

[Josh Davis]

When I tried updating to 0.3.4, the pre-commit hook started restoring files I had deleted.

Using git stash push --keep-index as in #30 restores deleted files to the working tree:

$ git init
Initialized empty Git repository in /tmp/git-stash-test/.git/
$ touch test
$ git add -A
$ git commit -m 'initial commit'
[master (root-commit) 5e0577e] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test
$ rm test
$ git add -A
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    test

$ git stash push --keep-index --message pre_commit
Saved working directory and index state On master: pre_commit
$ git stash pop
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    test

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        test

Dropped refs/stash@{0} (b6658734f4ae35a43bcff3f43b306ea6ae238902)

[Subil]

Man, I have looked long and hard to find a solution for this. I could not find one. Believe it or not, restoring the deleted file is the expected behavior for the git stash push --keep-index command. When you run the command, what it does is that it stores any unstaged changes to a stack and restores your git repo to the last commit. So that's why the deleted file reappears, because it is not deleted in the last commit. But since the command stores only the unstaged changes (the staged changes are not stored because of the --keep-index flag) and since you have already staged the deletion of the file, the deletion action is not stashed. So when you commit the deletion and then run git stash pop with the expectation that everything will go back to the way it was, the undeleted file will remain because git doesn't know that it was supposed to remove it (because the deletion action was never stashed by git because we had staged the deletion when we ran the git stash push command).

I hope this explanation makes sense. This has nerd sniped me and I hope someone will find a work around, because this seems to be a problem in the npm pre-commit package that this elixir package is based off of.

Edit: There seems to be some work done on this problem in the npm package but I haven't looked at it yet. Never mind, they run into the same problem too. I'm lost. Only thing I can think of now is to just be careful and make any new changes in a new branch and to not have unstaged changes in the branch you're going to run a commit on, avoiding the need for stash in the first place (though I really hope someone will solve this eventually).

[Zooey Miller]

Thanks for the research @secondspass! It would be great to find a way to deal with this but if it's a limitation of git, as it seems to be, then we may be a little stumped.

I think the best thing to do for now would be:

1. keep this issue open for visibility of the problem, maybe with a label to reflect the status
2. Update the readme / docs to let users know of this issue.

I'll sort the above this weekend :)

EDIT: added the wontfix label so that there isn't confusion. Hopefully at some point we can remove it.