I'm running into a problem when attempting to stash a submodule deletion when the submodule directory is empty. Below are the steps to reproduce.
$ git submodule add $SUBMODULE_URL path/to/submodule $ git commit -m "Add submodule" $ git rm path/to/submodule $ mkdir -p path/to/submodule $ git stash save error: path/to/submodule: is a directory - add files inside instead fatal: Unable to process path path/to/submodule Cannot save the current worktree state This problem came to light in a bug report filed for Overcommit <https://github.com/brigade/overcommit/issues/168>, a tool for managing git hooks. The tool stashes all changes using `git stash save --keep-index`, runs all configured pre-commit hooks, clears the working tree with `git reset --hard`, and reapplies the stash with `git stash pop --index`. If a pre-commit hook fails, the commit is aborted. If a hook fails when a submodule deletion is staged, attempting to commit again results in the error listed above. This is because the `git reset --hard` step from the first attempt restores the empty `path/to/submodule` directory, and on the second attempt, `git stash save` doesn't know what to do with it. This seems like a bug in git to me. Shouldn't `git stash save` be able to tell that the empty directory corresponds to a submodule staged for deletion, and simply leave it alone? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
