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

Johannes Schindelin [off-list ref] writes:

But it is sloppy, in that it blindly accepts options that might be valid
for several subcommands, not just "save".

I wouldn't call that sloppy. 'save' is the default command, if you
don't provide any command, then 'save' will be used.

So, "git stash -p" means "git stash save -p" regardless of the fact
that there exists somewhere else a "git stash list -p". Actually, in
the current form of pu, it is already the case since

f300fab (Thomas Rast, DWIM 'git stash save -p' for 'git stash -p')

which came right after your patch.

So please register my objection.

I will if you register my objection to yours ;-).

Jokes aside, if you insist in rejecting 'git stash -p', then my patch
can be slightly modified to say something like

+case "$1" in
+    -k|--keep-index|--patch)
+       set "save" "$@"
+       ;;
+esac

instead, which also allows multiple arguments (unlike your initial
proposal), and can control more precisely the list of options for
which 'save' is a default.

--
Matthieu

Hi,

On Tue, 18 Aug 2009, Matthieu Moy wrote:

Johannes Schindelin [off-list ref] writes:

quoted

But it is sloppy, in that it blindly accepts options that might be 
valid for several subcommands, not just "save".

I wouldn't call that sloppy. 'save' is the default command, if you don't 
provide any command, then 'save' will be used.

'save' might be the default command, but we don't trigger it with _any_ 
crap, for a very good reason.  Read the commit log for git-stash.sh to 
know why.

quoted

So please register my objection.

I will if you register my objection to yours ;-).

Jokes aside,

If you think that's funny, I don't.  I actually put a lot of thought into 
the issue whether to allow _any_ parameter with looks like an option to 
trigger "save".  And I very much had to come to the decision that no, that 
is too dangerous.

So I cannot take your objection seriously.

Ciao,
Dscho