{"thread":{"id":"20989","subject":"Usability question","startedAt":"2009-09-17T10:01:00Z","lastAt":"2009-09-20T18:54:15Z","messageCount":8,"participants":["Rob Barrett","Matthieu Moy","Owen Taylor","SZEDER Gábor","Daniele Segato","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"123434","messageId":"513ca40e0909170301s2b09184akb27acde76975c09b@mail.gmail.com","threadId":"20989","inReplyTo":null,"subject":"Usability question","fromName":"Rob Barrett","fromEmail":"barrettboy@gmail.com","sentAt":"2009-09-17T10:01:00Z","receivedAt":"2009-09-17T10:01:00Z","isPatch":false,"sender":{"key":"barrettboy@gmail.com","avatar":null},"body":"When starting with git people almost always ask some variant of \"how\ndo I know whether this option should be prefixed with dashes or not?\"\ni.e. git reset --hard vs. git stash save --patch, which coupled with\nother path, sha and treeish args make things a bit more confusing.\n\nNot sure if this has been discussed before? If it has point me at the\ndiscussion and I'll go look at it -- no need to read further.\n\nAnd people stop asking the question after they get used to git - but\nthat's not the same as being usable.\n\nOut of 60+ commands, most take the form\ngit [--option]\nand a few take the form\ngit subsubcommand [--option]\n\n(a quick scan gives: bisect,bundle,reflog,remote,stash)\n\nMy questions:\n1. What is the distinction that makes the 10% special enough to get\nnon-prefixed options?\n2. Is it worthwhile? Wouldn't it be better if to shoot for more\nconsistency / less complexity?\n\nRob\n"},{"id":"123435","messageId":"vpqy6odhn0d.fsf@bauges.imag.fr","threadId":"20989","inReplyTo":"513ca40e0909170301s2b09184akb27acde76975c09b@mail.gmail.com","subject":"Re: Usability question","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-09-17T10:41:06Z","receivedAt":"2009-09-17T10:41:06Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Rob Barrett writes:\n\n> My questions:\n> 1. What is the distinction that makes the 10% special enough to get\n> non-prefixed options?\n\nPrefixed and non-prefixed is what people usually call respectively\n\"options\" and \"subcommands\". To me, the distinction is needed:\n\nOptions are flags that modify the behavior of a git command. For\nexample, \"git reset\" and \"git reset --hard\" do something similar, but\n\"git svn rebase\" and \"git svn dcommit\" do something really, totally\ndifferent. It's not about doing the same thing in a different way,\nit's really about different actions.\n\nSubcommands are closer to commands than they are to options. The\nreason to group several subcommands into one command is mostly to\nreduce the number of commands, but for example, it could have been\ndecided to replace \"git svn dcommit\" by \"git svn-dcommit\" (but then\n\"git help\" would have been really really scarry).\n\n> 2. Is it worthwhile? Wouldn't it be better if to shoot for more\n> consistency / less complexity?\n\nWell, if you want to get rid of subcommands, why not get rid of\ncommands, too?\n\ngit --commit\ngit --status\ngit --svn --rebase\n\nI find the distinction between commands, subcommands and options\nreally helpfull.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"123438","messageId":"1253186420.11581.380.camel@localhost.localdomain","threadId":"20989","inReplyTo":"513ca40e0909170301s2b09184akb27acde76975c09b@mail.gmail.com","subject":"Re: Usability question","fromName":"Owen Taylor","fromEmail":"otaylor@redhat.com","sentAt":"2009-09-17T11:20:20Z","receivedAt":"2009-09-17T11:20:20Z","isPatch":false,"sender":{"key":"otaylor@redhat.com","avatar":"https://gravatar.com/avatar/407bd6b1c26601547f8e8dca44e191ddf414516a9536d822400bfab5ddc4ba69?d=mp&s=160"},"body":"On Thu, 2009-09-17 at 20:01 +1000, Rob Barrett wrote:\n> When starting with git people almost always ask some variant of \"how\n> do I know whether this option should be prefixed with dashes or not?\"\n> i.e. git reset --hard vs. git stash save --patch, which coupled with\n> other path, sha and treeish args make things a bit more confusing.\n> \n> Not sure if this has been discussed before? If it has point me at the\n> discussion and I'll go look at it -- no need to read further.\n> \n> And people stop asking the question after they get used to git - but\n> that's not the same as being usable.\n> \n> Out of 60+ commands, most take the form\n> git [--option]\n> and a few take the form\n> git subsubcommand [--option]\n> \n> (a quick scan gives: bisect,bundle,reflog,remote,stash)\n> \n> My questions:\n> 1. What is the distinction that makes the 10% special enough to get\n> non-prefixed options?\n> 2. Is it worthwhile? Wouldn't it be better if to shoot for more\n> consistency / less complexity?\n\nI don't think anybody is going to say that it all makes perfect sense. \nOne pattern is:\n\n git \n\nvs.\n\n git (gui, svn, ...)\n git (bundle, remote, stash, submodule, ...)\n\nAnother pattern is that options don't change the verb, they just \nmodify it. \n\nBut it's easy to find exceptions:\n\n git tag -l\n git branch --contains \n git am --abort\n\nI personally think it would help consistency to use the subsubcommand\npattern more and treat 'git tag ' as an shorthand. If you really\nwant to to create a tag called 'list', you'd need to use\n'git tag tag list', or maybe 'git tag -- list'.\n\nEven with compat support for options and a general agreement that I\ndoubt exists, that's at best a 95% compatible change, so it's unlikely\nto happen soon.\n\n- Owen\n"},{"id":"123442","messageId":"20090917121328.GA21837@neumann","threadId":"20989","inReplyTo":"vpqy6odhn0d.fsf@bauges.imag.fr","subject":"Re: Usability question","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2009-09-17T12:13:28Z","receivedAt":"2009-09-17T12:13:28Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\nOn Thu, Sep 17, 2009 at 12:41:06PM +0200, Matthieu Moy wrote:\n> Rob Barrett writes:\n> > 1. What is the distinction that makes the 10% special enough to get\n> > non-prefixed options?\n> \n> Prefixed and non-prefixed is what people usually call respectively\n> \"options\" and \"subcommands\". To me, the distinction is needed:\n> \n> Options are flags that modify the behavior of a git command. For\n> example, \"git reset\" and \"git reset --hard\" do something similar, but\n> \"git svn rebase\" and \"git svn dcommit\" do something really, totally\n> different. It's not about doing the same thing in a different way,\n> it's really about different actions.\n\nI tend to aggree, but what about 'git rebase --abort' vs. 'git rebase\n--continue'? IMHO they are also doing something totally different.\n\n\nBest,\nGábor\n"},{"id":"123446","messageId":"vpqiqfhbtve.fsf@bauges.imag.fr","threadId":"20989","inReplyTo":"20090917121328.GA21837@neumann","subject":"Re: Usability question","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-09-17T13:09:25Z","receivedAt":"2009-09-17T13:09:25Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"SZEDER Gábor writes:\n\n> I tend to aggree, but what about 'git rebase --abort' vs. 'git rebase\n> --continue'? IMHO they are also doing something totally different.\n\nIf I were to rewrite it, I'd call them \"git rebase abort\" without\ndashes. Not sure renaming them to subcommands is worth it though.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"123449","messageId":"9accb4400909170625v35e112f6i66d79282d2433c49@mail.gmail.com","threadId":"20989","inReplyTo":"vpqy6odhn0d.fsf@bauges.imag.fr","subject":"Re: Usability question","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2009-09-17T13:25:29Z","receivedAt":"2009-09-17T13:25:29Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"On Thu, Sep 17, 2009 at 12:01 PM, Rob Barrett wrote:\n> When starting with git people almost always ask some variant of \"how\n> do I know whether this option should be prefixed with dashes or not?\"\n> i.e. git reset --hard vs. git stash save --patch, which coupled with\n> other path, sha and treeish args make things a bit more confusing.\n\n> And people stop asking the question after they get used to git - but\n> that's not the same as being usable.\n\nwithout speaking of usability I'll tell them to use autocompletion to\nsee which command / options they have until\nthey get used to them\n\nregards,\nDaniele\n"},{"id":"123528","messageId":"513ca40e0909191921k1b7b14b5j7cfd8734441397d9@mail.gmail.com","threadId":"20989","inReplyTo":"vpqy6odhn0d.fsf@bauges.imag.fr","subject":"Re: Usability question","fromName":"Rob Barrett","fromEmail":"barrettboy@gmail.com","sentAt":"2009-09-20T02:21:38Z","receivedAt":"2009-09-20T02:21:38Z","isPatch":false,"sender":{"key":"barrettboy@gmail.com","avatar":null},"body":"On Thu, Sep 17, 2009 at 8:41 PM, Matthieu Moy\n wrote:\n> Well, if you want to get rid of subcommands, why not get rid of\n> commands, too?\n>\n> git --commit\n> git --status\n> git --svn --rebase\n>\n\nWell, granted, that's a sort of heavyweight consistency, but all we\nshould need to do is to help reduce a _new_ user's confusion about\nwhen the word after a subcommand gets a '--' prefix and when it\ndoesn't.\n\nAnd do it in a way that's backwards compatible so it doesn't affect\nthe usage patterns of seasoned users, existing scripts, crons etc.\n\nWill patch and see how it looks..\n\nRob\n"},{"id":"123550","messageId":"20090920185415.GA6988@dpotapov.dyndns.org","threadId":"20989","inReplyTo":"513ca40e0909191921k1b7b14b5j7cfd8734441397d9@mail.gmail.com","subject":"Re: Usability question","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-09-20T18:54:15Z","receivedAt":"2009-09-20T18:54:15Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Sep 20, 2009 at 12:21:38PM +1000, Rob Barrett wrote:\n> On Thu, Sep 17, 2009 at 8:41 PM, Matthieu Moy\n> wrote:\n> > Well, if you want to get rid of subcommands, why not get rid of\n> > commands, too?\n> >\n> > git --commit\n> > git --status\n> > git --svn --rebase\n> >\n> \n> Well, granted, that's a sort of heavyweight consistency, but all we\n> should need to do is to help reduce a _new_ user's confusion about\n> when the word after a subcommand gets a '--' prefix and when it\n> doesn't.\n> \n> And do it in a way that's backwards compatible so it doesn't affect\n> the usage patterns of seasoned users, existing scripts, crons etc.\n> \n> Will patch and see how it looks..\n\nIt will be horrible broken... Do you realize that there is a bigger\ndifference between commands and options than just that commands are\nwritten without a '--' prefix? Take a look at the following commands:\n\n$ git -p log\n$ git log -p\n\nThere are completely difference because in the former case the -p\noption modifies 'git' behavior while in the later case 'git log'.\n\nIf you change commands to options, you are going to break everything.\n\n\nDmitry\n"}]}