[PATCH] Clarify how the user can satisfy stash's 'dirty state' check.

[PATCH] Clarify how the user can satisfy stash's 'dirty state' check.

[Stephen Haberman]

Clarify how the user can satisfy stash's 'dirty state' check.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---

Feel free to tweak the wording, but we had a false assumption that you
could not apply multiple stashes in a row due to this confusing error
message. I.e. "dirty state" was taken as "dirty working tree and/or
index" instead of just "dirty working tree".

I don't have any tests, but t3903-stash.sh runs the same ("10: stash
branch" is failing both before and after my change change).

Looking into it more, I dislike that t3903's "3: apply needs clean
working directory" uses test_must_fail because without actively
asserting that the expected error message comes back, we can't be sure
the boundary condition that was originally tested for is still being met
(e.g. `git stash` could be returning non-zero for some entirely
different reason now--not likely, yes, but possible). test_must_fail
mentions a "segv" reason, which I'll somewhat blindly accept as good,
but it would be nice if I could pass in/grep against/something the error
message. Perhaps on another line/invocation?

Anyway...the patch:

 git-stash.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index e15c12a..a932ca7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -151,7 +151,7 @@ show_stash () {
 
 apply_stash () {
 	git diff-files --quiet --ignore-submodules ||
-		die 'Cannot restore on top of a dirty state'
+		die 'Cannot apply to a dirty working tree, please stage your changes'
 
 	unstash_index=
 	case "$1" in
-- 
1.6.0.2