{"thread":{"id":"37197","subject":"Unify subcommand structure; introduce double dashes for all subcommands?","startedAt":"2014-07-23T13:35:22Z","lastAt":"2014-08-10T21:08:03Z","messageCount":5,"participants":["Stefan Beller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"246559","messageId":"53CFBA1A.8040600@gmail.com","threadId":"37197","inReplyTo":null,"subject":"Unify subcommand structure; introduce double dashes for all subcommands?","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-07-23T13:35:22Z","receivedAt":"2014-07-23T13:35:22Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"In the user survey 2012 question 23 (\"In your opinion, which areas in\nGit need improvement?\"),\nthe most crucial point identified was the user interface.\nI wonder if there are any more recent surveys, showing if this has changed.\nNow when we want to improve the user interface, we're likely talking\nabout the porcelain\ncommands only, as that's what most users perceive as the commandline\nuser interface.\n\nA git command is generally setup as:\n\tgit <command> [<subcommand>] [<options>] ...\n\nThe subcommands vary wildly by the nature of the command. However all\nsubcommands\ncould at least follow one style. The commands bundle, notes, stash and\nsubmodule\nhave subcommands without two leading dashes (i.e. git stash list) as\nopposed to all\nother commands (i.e. git tag --list).\n\nSo my proposal is to unify the structure of the subcommands to either\nhave always\nleading dashes or never. This would need a longterm thinking of course\n(e.g. introduce new options with(out) dashes, but support existing\ncommands until git 3.0\nor such, then drop them.)\n\nWas there a discussion about this topic already?\nI'd like to read on these discussions, if any.\n\nI could think about the following points being interesting\n * user interface (what is more appealing to a user?)\n * ease of transition (Is it really worth it? How long does it take to\npay off?)\n * ease of implementation (Could we reuse the option parser already in\n   place for the double-dashed subcommands, i.e. have less LoC)\n * error-proneness of the transition\n\nThanks,\nStefan\n"},{"id":"246581","messageId":"xmqqiomodkt9.fsf@gitster.dls.corp.google.com","threadId":"37197","inReplyTo":"53CFBA1A.8040600@gmail.com","subject":"Re: Unify subcommand structure; introduce double dashes for all subcommands?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-07-23T17:52:34Z","receivedAt":"2014-07-23T17:52:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <stefanbeller@gmail.com> writes:\n\n> A git command is generally setup as:\n> \tgit <command> [<subcommand>] [<options>] ...\n>\n> The subcommands vary wildly by the nature of the command. However all\n> subcommands\n> could at least follow one style. The commands bundle, notes, stash and\n> submodule\n> have subcommands without two leading dashes (i.e. git stash list) as\n> opposed to all\n> other commands (i.e. git tag --list).\n\nSounds familiar.  E.g. here is a similar thread about a year ago.\n\n  http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478\n\nFurther discussions to make the plan more concrete is very much\nwelcomed.\n\nThanks.\n"},{"id":"247555","messageId":"53E78F26.3000701@gmail.com","threadId":"37197","inReplyTo":"xmqqiomodkt9.fsf@gitster.dls.corp.google.com","subject":"Re: Unify subcommand structure; introduce double dashes for all subcommands?","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-08-10T15:26:30Z","receivedAt":"2014-08-10T15:26:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 23.07.2014 19:52, Junio C Hamano wrote:\n> Stefan Beller <stefanbeller@gmail.com> writes:\n> \n>> A git command is generally setup as:\n>> \tgit <command> [<subcommand>] [<options>] ...\n>>\n>> The subcommands vary wildly by the nature of the command. However all\n>> subcommands\n>> could at least follow one style. The commands bundle, notes, stash and\n>> submodule\n>> have subcommands without two leading dashes (i.e. git stash list) as\n>> opposed to all\n>> other commands (i.e. git tag --list).\n> \n> Sounds familiar.  E.g. here is a similar thread about a year ago.\n> \n>   http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478\n> \n> Further discussions to make the plan more concrete is very much\n> welcomed.\n> \n> Thanks.\n> \n\nSo I'd want to add have the subcommands without double dashes ideally.\nIt's just less typing and more english like, not cryptic with dashes. \nThis may come handy for newcomers/beginners using git. It also benefits \nthe powerusers of git as you spare the typing of 2 dashes on the subcommand.\n\nI'm currently trying to understand the functions to parse options \nand I wonder if the following is possible:\n\nIf there is an option set by OPT_CMDMODE \n(such as git tag --delete / --verify) we want to add an internal option,\n(such as PARSE_OPT_NODASH ?), \nthat you can deliver this CMD_MODE option without leading 2 dashes. \nThe current behavior with leading 2 dashes is still supported, \nbut maybe a warning is printed about deprecating the option with 2 dashes.\n\nHaving this change in place will switch over revert, replace, tag and merge-base\nto having sane subcommands without dashes possible.\n\nOnce this change is in, we can rewrite the other commands, \nwhich as of now don't require the dashes.\nCoincidentally these commands heavily rely on option parsing themselves,\nsuch as git-notes having this code in place:\n\n\tif (argc < 1 || !strcmp(argv[0], \"list\"))\n\t\tresult = list(argc, argv, prefix);\n\telse if (!strcmp(argv[0], \"add\"))\n\t\tresult = add(argc, argv, prefix);\n\telse if (!strcmp(argv[0], \"copy\"))\n\t\tresult = copy(argc, argv, prefix);\n\t...\n\nDoes that make sense?\nStefan\n"},{"id":"247557","messageId":"xmqqha1k8b6v.fsf@gitster.dls.corp.google.com","threadId":"37197","inReplyTo":"53E78F26.3000701@gmail.com","subject":"Re: Unify subcommand structure; introduce double dashes for all subcommands?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-08-10T18:13:44Z","receivedAt":"2014-08-10T18:13:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <stefanbeller@gmail.com> writes:\n\n> On 23.07.2014 19:52, Junio C Hamano wrote:\n>\n>> Sounds familiar.  E.g. here is a similar thread about a year ago.\n>> \n>>   http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478\n>> \n>> Further discussions to make the plan more concrete is very much\n>> welcomed.\n>> \n>> Thanks.\n>> \n>\n> So I'd want to add have the subcommands without double dashes ideally.\n\nThat is not ideal at all, I am afraid.  A command that started only\nwith its \"primary operating mode\", e.g. \"git tag [-s|-a] tagname\n[object]\", may have to gain \"I do not want to create, I just want to\nlist\" and the way to signal that has to be an option that cannot be\nmistaken as its valid first argument (to avoid \"git tag list\" that\ncannot create a tag called \"list\", we use \"git tag --list\").  You\ncould add an entirely new command \"git foo\" that always takes the\ncommand-mode word, i.e. \"git foo mode$n args\", but you will be\ntyping the operating mode name all the time only to save --mode$n\nfor 2<=$n, which may not be a good economy in the end.\n\nPlease do not go there.\n"},{"id":"247562","messageId":"53E7DF33.50508@gmail.com","threadId":"37197","inReplyTo":"xmqqha1k8b6v.fsf@gitster.dls.corp.google.com","subject":"Re: Unify subcommand structure; introduce double dashes for all subcommands?","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-08-10T21:08:03Z","receivedAt":"2014-08-10T21:08:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 10.08.2014 20:13, Junio C Hamano wrote:\n> Stefan Beller <stefanbeller@gmail.com> writes:\n> \n>> On 23.07.2014 19:52, Junio C Hamano wrote:\n>>\n>>> Sounds familiar.  E.g. here is a similar thread about a year ago.\n>>>\n>>>   http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478\n>>>\n>>> Further discussions to make the plan more concrete is very much\n>>> welcomed.\n>>>\n>>> Thanks.\n>>>\n>>\n>> So I'd want to add have the subcommands without double dashes ideally.\n> \n> That is not ideal at all, I am afraid.  A command that started only\n> with its \"primary operating mode\", e.g. \"git tag [-s|-a] tagname\n> [object]\", may have to gain \"I do not want to create, I just want to\n> list\" and the way to signal that has to be an option that cannot be\n> mistaken as its valid first argument (to avoid \"git tag list\" that\n> cannot create a tag called \"list\", we use \"git tag --list\").  You\n> could add an entirely new command \"git foo\" that always takes the\n> command-mode word, i.e. \"git foo mode$n args\", but you will be\n> typing the operating mode name all the time only to save --mode$n\n> for 2<=$n, which may not be a good economy in the end.\n> \n> Please do not go there.\n> \n\nI see your point.\nHowever how often do you really want to create a tag called list?\nAs of now it's easy:\n\tgit tag list\nand for listing all tags you'd need to type:\n\tgit tag --list\nand if you want to create a tag called --list, I'd assume you'd go\n\tgit tag -- --list\n\t# However:\n\tfatal: '--list' is not a valid tag name.\n\nSo even as of now certain tag names cannot be done easily.\nAlso you have to type two more dashes for an action you'd probably want\nto perform more often (as opposed to creating a tag 'list')\n\nIn my (ideal) world we'd rather have this behavior:\n \tgit tag list\n\t# behaves the same as\n\tgit tag\n\nNow creating a tag called 'list' is not as easy, because 'list' is a\nprimary operating mode name, so we need to tell git we're actually\nmeaning the name as opposed to the operating mode:\n\tgit tag create -- list\n\t# or even\n\tgit tag create -- --list\n\n\n\n----\nAnyways despite my arguing, it seems you rather want to rather have the\nleading double dashes everywhere for the operating modes?\nSo the plan is to not touch the parsing, but to adjust notes and stash ?\n\nThanks,\nStefan\n"}]}