Add failing test case for restoring unstaged changes

[jawshooah]

Add test case for Overcommit::HookContext::PreCommit#cleanup_environment to check that unstaged changes are restored when no changes were staged. This test is currently failing.

This is likely a regression introduced by #149. My bad. Fix incoming in a separate PR.

[jawshooah]

Pushed the fix on this branch instead of in a separate PR.

[sds]

I would rather have the fix for this accompanying the newly introduced tests. However, I can see why you didn't come up with a fix yet, as the problem is rather nuanced.

Some facts:

1. You can git stash adding a submodule (you'll get a warning that a non-empty directory—the submodule directory—can't be removed, but it works), and restore it with git stash pop
2. You can't stash changes to a submodule

I'm a little confused as to the reasoning behind 2, so I've posted a question to the Git mailing list. I would link to the archive but it appears to be down at the moment.

Here is the question I posed to the list:

I’m having trouble understanding why I cannot stash changes to a submodule.

When adding a submodule to a repository (git submodule add ./sub-repo), I can then run git stash and git stash pop with
expected results—the submodule disappears and reappears in the working
tree.

However, when I try stashing an update to a submodule, git stash
reports “No local changes to save”. The following shell script
illustrates this behavior:

# Create repo
mkdir test-repo
cd test-repo
git init
git commit --allow-empty -m "Initial commit"

# Create submodule
mkdir sub-repo
cd sub-repo
git init
git commit --allow-empty -m "Initial commit"
cd -

# Add submodule
git submodule add ./sub-repo
git commit -m "Add submodule"

# Modify submodule
cd sub-repo
touch foo
git add foo
git commit -m "Submodule changed"
cd -

# Stash submodule change
git stash # <---------------------------Displays "No local changes to save”

I’m trying to wrap my head around why this is the current behavior, as
I suspect this is intentional but it seems unexpected. If anyone can
shed any light on this, I would really appreciate it!

Thanks,

Shane

I'll let you know if I hear anything back. However, it looks like we're going to need to special case submodules so that even though git doesn't stash them we "stash" changes on behalf of the user.

[sds]

Ah, I see you merged a fix. Great!

However, doesn't this still result in submodule changes being lost, since when we git reset --hard any submodule changes will be destroyed and not restored in the subsequent git stash pop?

[jawshooah]

The specs for submodule-only changes still pass, so we know that when only submodule changes are staged, everything works as expected. We should add specs for when submodule changes are staged in addition to file-level changes for completeness.

[jawshooah]

@sds I've added specs to check that submodule changes are preserved when staged along with file changes. All green.

[jawshooah]

You could also post your question to the git-users Google group in case the mailing list is down.

[sds]

Nice! For some reason I thought I had tested running git reset --hard with submodule changes and had confirmed they were lost. Looks like that's not the case (and I've indeed confirmed it).