From: Owen Taylor Date: Thu, 17 Sep 2009 11:20:20 GMT Subject: Re: Usability question Message-ID: <1253186420.11581.380.camel@localhost.localdomain> In-Reply-To: <513ca40e0909170301s2b09184akb27acde76975c09b@mail.gmail.com> On Thu, 2009-09-17 at 20:01 +1000, Rob Barrett wrote: > When starting with git people almost always ask some variant of "how > do I know whether this option should be prefixed with dashes or not?" > i.e. git reset --hard vs. git stash save --patch, which coupled with > other path, sha and treeish args make things a bit more confusing. > > Not sure if this has been discussed before? If it has point me at the > discussion and I'll go look at it -- no need to read further. > > And people stop asking the question after they get used to git - but > that's not the same as being usable. > > Out of 60+ commands, most take the form > git [--option] > and a few take the form > git subsubcommand [--option] > > (a quick scan gives: bisect,bundle,reflog,remote,stash) > > My questions: > 1. What is the distinction that makes the 10% special enough to get > non-prefixed options? > 2. Is it worthwhile? Wouldn't it be better if to shoot for more > consistency / less complexity? I don't think anybody is going to say that it all makes perfect sense. One pattern is: git vs. git (gui, svn, ...) git (bundle, remote, stash, submodule, ...) Another pattern is that options don't change the verb, they just modify it. But it's easy to find exceptions: git tag -l git branch --contains git am --abort I personally think it would help consistency to use the subsubcommand pattern more and treat 'git tag ' as an shorthand. If you really want to to create a tag called 'list', you'd need to use 'git tag tag list', or maybe 'git tag -- list'. Even with compat support for options and a general agreement that I doubt exists, that's at best a 95% compatible change, so it's unlikely to happen soon. - Owen