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.

Reply via email to