[PATCH] Clarify how the user can satisfy stash's 'dirty state' check.
- From
Stephen Haberman <stephen@exigencecorp.com>
- Date
- Sep 29, 2008, 09:12 UTC
- Message-ID
- <20080929041204.846ba617.stephen@exigencecorp.com>
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