Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 18, 2009, 20:20 UTC
- Message-ID
- <7vbpmcc1sc.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20090818174509.GA27518@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 23 quoted lines
> On Tue, Aug 18, 2009 at 03:01:52PM +0200, Matthieu Moy wrote: > ... > I think yours is nicer, especially as we have just added the > '-p|--patch' option, as well. With what is there now, you can do "git > stash -p", but not "git stash -p -k". > >> But I may have missed its drawbacks ;-) > > The only I can think of is that bogus input will provoke 'save'. So > something like: > > git stash --apply > > will invoke "git stash save --apply", which doesn't even complain. It > just tries to make a stash with message --apply. Now of course this > input is obviously bogus, but probably the right thing to do is > complain. > > OTOH, I think it is the fault of "git stash save --apply" for not doing > the complaining, so your patch really isn't making it worse. Probably it > should barf on anything unrecognized starting with a '-', and allow '--' > to separate the message from the rest of the options (in the rare case > that you want a message starting with '-').
Sounds like a sane approach.
I am Ok with the idea of queuing a patch to update js/stash-dwim ea41cfc (Make 'git stash -k' a short form for 'git stash save --keep-index', 2009-07-27) with an implementation along this line; the "stash -p" one f300fab (DWIM 'git stash save -p' for 'git stash -p', 2009-08-13) also may need to adjusted (it could become no-op, I suspect).