git/git-stash.sh, branch v2.4.9

Merge branch 'jk/stash-require-clean-index' into maint

2015-06-26T06:03:27Z

A hotfix for the topic already in 'master'. * jk/stash-require-clean-index: Revert "stash: require a clean index to apply"

Merge branch 'jk/stash-options' into maint

2015-06-16T21:33:43Z

Make "git stash something --help" error out, so that users can safely say "git stash drop --help". * jk/stash-options: stash: recognize "--help" for subcommands stash: complain about unknown flags

Revert "stash: require a clean index to apply"

2015-06-15T20:11:17Z

This reverts commit ed178ef13a26136d86ff4e33bb7b1afb5033f908. That commit was an attempt to improve the safety of applying a stash, because the application process may create conflicted index entries, after which it is hard to restore the original index state. Unfortunately, this hurts some common workflows around "git stash -k", like: git add -p ;# (1) stage set of proposed changes git stash -k ;# (2) get rid of everything else make test ;# (3) make sure proposal is reasonable git stash apply ;# (4) restore original working tree If you "git commit" between steps (3) and (4), then this just works. However, if these steps are part of a pre-commit hook, you don't have that opportunity (you have to restore the original state regardless of whether the tests passed or failed). It's possible that we could provide better tools for this sort of workflow. In particular, even before ed178ef, it could fail with a conflict if there were conflicting hunks in the working tree and index (since the "stash -k" puts the index version into the working tree, and we then attempt to apply the differences between HEAD and the old working tree on top of that). But the fact remains that people have been using it happily for a while, and the safety provided by ed178ef is simply not that great. Let's revert it for now. In the long run, people can work on improving stash for this sort of workflow, but the safety tradeoff is not worth it in the meantime. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

stash: recognize "--help" for subcommands

2015-05-20T20:47:41Z

If you run "git stash --help", you get the help for stash (this magic is done by the git wrapper itself). But if you run "git stash drop --help", you get an error. We cannot show help specific to "stash drop", of course, but we can at least give the user the normal stash manpage. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

stash: complain about unknown flags

2015-05-20T20:47:30Z

The option parser for git-stash stuffs unknown flags into the $FLAGS variable, where they can be accessed by the individual commands. However, most commands do not even look at these extra flags, leading to unexpected results like this: $ git stash drop --help Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1) We should notice the extra flags and bail. Rather than annotate each command to reject a non-empty $FLAGS variable, we can notice that "stash show" is the only command that actually _wants_ arbitrary flags. So we switch the default mode to reject unknown flags, and let stash_show() opt into the feature. Reported-by: Vincent Legoll Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

stash: require a clean index to apply

2015-04-22T20:38:58Z

If you have staged contents in your index and run "stash apply", we may hit a conflict and put new entries into the index. Recovering to your original state is difficult at that point, because tools like "git reset --keep" will blow away anything staged. We can make this safer by refusing to apply when there are staged changes. It's possible we could provide better tooling here, as "git stash apply" should be writing only conflicts to the index (so we know that any stage-0 entries are potentially precious). But it is the odd duck; most "mergy" commands will update the index for cleanly merged entries, and it is not worth updating our tooling to support this use case which is unlikely to be of interest (besides which, we would still need to block a dirty index for "stash apply --index", since that case _would_ be ambiguous). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'da/rev-parse-verify-quiet'

2014-09-29T19:36:10Z

"rev-parse --verify --quiet $name" is meant to quietly exit with a non-zero status when $name is not a valid object name, but still gave error messages in some cases. * da/rev-parse-verify-quiet: stash: prefer --quiet over shell redirection of the standard error stream refs: make rev-parse --quiet actually quiet t1503: use test_must_be_empty Documentation: a note about stdout for git rev-parse --verify --quiet

Merge branch 'ah/grammofix'

2014-09-19T18:38:35Z

* ah/grammofix: grammofix in user-facing messages

stash: prefer --quiet over shell redirection of the standard error stream

2014-09-19T17:51:59Z

Use `git rev-parse --verify --quiet` instead of redirecting stderr to /dev/null. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Merge branch 'jk/stash-list-p'

2014-09-09T19:54:00Z

Teach "git stash list -p" to show the difference between the base commit version and the working tree version, which is in line with what "git show" gives. * jk/stash-list-p: stash: default listing to working-tree diff