Clarify how the user can satisfy stash's 'dirty state' check.
Signed-off-by: Stephen Haberman <stephen@xxxxxxxxxxxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
