Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted

[Jeff King <peff@peff.net>]

On Wed, Aug 19, 2009 at 12:46:27AM +0200, Johannes Schindelin wrote:

> So if I say "git stash -q" by mistake, but wanted to say "git stash drop 
> -q", then I am borked?
> 
> Bah!  I say: bah!

Yep, though it is only one of many borkings that currently exist. Try:

  # oops, what was the name of that option?
  git stash save --index

  # does apply take --patch, too?
  git stash apply --patch

Still, other parts of the option parsing being awful aren't an excuse to
mess this one up. So I see your point.

> You're basically reintroducing at least part of the DWIMery that was 
> reverted in 9488e875 and I have the distinct feeling that some people in 
> this thread do not think hard enough about what would adher to the 
> principle of least surprise even in the future (or even for people 
> introducing other stash save options).

I don't think it is quite as bad as that, as arbitrary crap will not get
passed through, only crap that looks like options. Which is perhaps a
step up, but it is debatable how much.

I think Matthieu's proposal to be strict about matching the options, but
to take multiple options is probably the best bet for now. As it is now,
accepting "git stash -k" or "git stash -p" but not "git stash -k -p" is
pretty counterintuitive. But with explicit matching it should be no less
safe than it is now.

> Well, you just go ahead and push through your patch, and I do what I 
> promised on my blog.

I don't know why you need to be so confrontational. I don't even have a
patch to "push through". I just said "I don't see the problem", and I'm
glad you brought up the previous stash behavior, because I had forgotten
the pain it caused. And that is why discussing on a public forum is
nice; it lets people contribute things that others might have missed.

-Peff