Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:47:16

Johannes Schindelin [off-list ref] writes:
Hi,

On Tue, 18 Aug 2009, Matthieu Moy wrote:
quoted
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.
The good reason was people doing a typo when typing a command, like
'git stash aply' or so. And yes, I did find this annoying. The
question of someone omitting the subcommand is very different to me.
On can hardly type 'git stash -q' and claim he explicitely wanted to
run 'pop'.

Your proposal will almost certainly trigger complains from users:

git stash -k => works
git stash -k -q => doesn't work
git stash -k "name of stash" => doesn't work
git stash save -k "name of stash" => works
git stash -p => works with another patch merged in next
git stash -q => doesn't work
git stash --patch --no-keep-index => works
git stash --no-keep-index --patch => doesn't work

You'll have a hard time explaining that to bare mortals.

Look at what's the code's becomming:

+       0,,|1,-k,|1,--keep-index,|1,-p,|1,--patch,|2,-p,--no-keep-index|2,--patch,--no-keep-index)

when the code starts having to enumerate so many possibilities instead
of having a simple logic, something's going wrong.

-- 
Matthieu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help