{"thread":{"id":"40171","subject":"Git's inconsistent command line options","startedAt":"2015-08-25T08:01:24Z","lastAt":"2015-09-09T09:42:54Z","messageCount":25,"participants":["Graeme Geldenhuys","Junio C Hamano","Jacob Keller","Stefan Beller","Hilco Wijbenga","Andreas Schwab","Philip Oakley","Duy Nguyen","Barry Warsaw","David Aguilar","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"268629","messageId":"mrh7ck$r0g$1@ger.gmane.org","threadId":"40171","inReplyTo":null,"subject":"Git's inconsistent command line options","fromName":"Graeme Geldenhuys","fromEmail":"graemeg@gmail.com","sentAt":"2015-08-25T08:01:24Z","receivedAt":"2015-08-25T08:01:24Z","isPatch":false,"sender":{"key":"graemeg@gmail.com","avatar":"https://gravatar.com/avatar/fdaae0cf0a07bd33782720fb37ae0450f504d4e04c57c6e8f3517d11d503fdc6?d=mp&s=160"},"body":"Hi,\n\nI've used Git for years and this has always bothered me. Has anybody\nelse noticed the inconsistent command line parameteres for seemingly\nsimilar tasks. There are many examples, but I'll list only two (I can\nsupply a more extensive list if needed).\n\neg: Renaming things.\n\n * When working with branches it uses \"-m\" or \"-M\" to rename a branch.\n\n * When working with remote repos it use \"rename\" (not even the more\ncommon -- prefix either).\n\neg: Deleting things\n\n * When working with branches it uses \"-d\" or \"-D\" to delete a branch\n\n * When working with remote branch it uses only a push command.\n\n * When deleting a remote repo it uses \"remove\" (again not even with\nthe commonly used -- prefix)\n\n\nEven though I have worked with Git since 2009, I still have to\nreference the help to remind me of what parameter to use in certain\nsituation simply because similar tasks differ so much.\n\nMaybe we could address this in the next major version of Git? Has\nanybody else thought about this or started work on this? Or was this\ndiscussed before and declined (link?).\n\nRegards,\n Graeme\n"},{"id":"268651","messageId":"CAPc5daUdVQSAhrig046qGopVuxCDagZg3v9bwXOaC3SvC2MRnw@mail.gmail.com","threadId":"40171","inReplyTo":"mrh7ck$r0g$1@ger.gmane.org","subject":"Re: Git's inconsistent command line options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-25T15:13:08Z","receivedAt":"2015-08-25T15:13:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys wrote:\n>\n> Even though I have worked with Git since 2009, I still have to\n> reference the help to remind me of what parameter to use in certain\n> situation simply because similar tasks differ so much.\n>\n> Maybe we could address this in the next major version of Git? Has\n> anybody else thought about this or started work on this? Or was this\n> discussed before and declined (link?).\n\nhttp://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,\nwhich has been linked from this entry:\n\nDiscuss and decide if we want to choose between the \"mode word\" UI\n(e.g. \"git submodule add\") and the \"mode option\" UI (e.g. \"git tag --delete\")\nand standardise on one; if it turns out to be a good idea, devise the migration\nplan to break the backward-compatibility.\n\nin http://git-blame.blogspot.com/p/leftover-bits.html\n"},{"id":"268696","messageId":"CA+P7+xrYugueYYrrJV0pduAHCg7CLknE_0QYcU8mO6idntz=VA@mail.gmail.com","threadId":"40171","inReplyTo":"CAPc5daUdVQSAhrig046qGopVuxCDagZg3v9bwXOaC3SvC2MRnw@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-25T21:49:10Z","receivedAt":"2015-08-25T21:49:10Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:\n> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys wrote:\n>>\n>> Even though I have worked with Git since 2009, I still have to\n>> reference the help to remind me of what parameter to use in certain\n>> situation simply because similar tasks differ so much.\n>>\n>> Maybe we could address this in the next major version of Git? Has\n>> anybody else thought about this or started work on this? Or was this\n>> discussed before and declined (link?).\n>\n> http://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,\n> which has been linked from this entry:\n>\n> Discuss and decide if we want to choose between the \"mode word\" UI\n> (e.g. \"git submodule add\") and the \"mode option\" UI (e.g. \"git tag --delete\")\n> and standardise on one; if it turns out to be a good idea, devise the migration\n> plan to break the backward-compatibility.\n>\n> in http://git-blame.blogspot.com/p/leftover-bits.html\n\nI would vote for command words, as this is clean and simple. The\ndownside is in converting all the old options based commands, git-tag,\nand similar. These commands cannot easily convert because \"valid\"\nsequences would become invalid with no easy way to deprecate for\nexample in the linked gmane above, \"git tag delete master\" can't be a\ncall to delete master as it is currently a call to create a tag\n\"delete\" at the commit marked by master.\n\nI can't think of an easy way to deprecate the change in behavior over\ntime, which means that making a conversion would require some other as\nyet unknown way?\n\nIt may be possible to convert other options based commands, such as\nhow git-branch and git-checkout do things which seem highly unrelated.\nA good example is how checkout is used to both change branches, as\nwell as can create a branch, and can also checkout a file. The \"reset\"\ncommand is used to rewind history, as well as potentially reset *all*\nfiles, but it can't be used to reset a single file, and is completely\ndifferent from revert. Some of these distinctions are ok because it's\njust no good way to make everything easy.\n\nSome of these could be fixed by the command word setup, but as many\nhave mentioned an actual migration plan is difficult.\n\nPersonally, I don't want to move to the command option \"--status\"\nformat, as I think these aren't really options, and are very much\nsub-subcommands. I think we should try to push more uses of this\nstyle, and try to determine a possible migration path towards using\nthem. Maybe some warts simply aren't worth the effort to fix though.\n\nOther issues are tricker to solve, and are result of git exposing more\ncomplex functionality and users eventually simply have to learn and\nunderstand.\n\nRegards,\nJake\n"},{"id":"268697","messageId":"CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com","threadId":"40171","inReplyTo":"CA+P7+xrYugueYYrrJV0pduAHCg7CLknE_0QYcU8mO6idntz=VA@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-08-25T22:06:20Z","receivedAt":"2015-08-25T22:06:20Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller wrote:\n> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:\n>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys wrote:\n>>>\n>>> Even though I have worked with Git since 2009, I still have to\n>>> reference the help to remind me of what parameter to use in certain\n>>> situation simply because similar tasks differ so much.\n>>>\n>>> Maybe we could address this in the next major version of Git? Has\n>>> anybody else thought about this or started work on this? Or was this\n>>> discussed before and declined (link?).\n>>\n>> http://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,\n>> which has been linked from this entry:\n>>\n>> Discuss and decide if we want to choose between the \"mode word\" UI\n>> (e.g. \"git submodule add\") and the \"mode option\" UI (e.g. \"git tag --delete\")\n>> and standardise on one; if it turns out to be a good idea, devise the migration\n>> plan to break the backward-compatibility.\n>>\n>> in http://git-blame.blogspot.com/p/leftover-bits.html\n>\n> I would vote for command words, as this is clean and simple.\n\nme too after rereading the arguments in that thread.\n\n> The\n> downside is in converting all the old options based commands, git-tag,\n> and similar. These commands cannot easily convert because \"valid\"\n> sequences would become invalid with no easy way to deprecate for\n> example in the linked gmane above, \"git tag delete master\" can't be a\n> call to delete master as it is currently a call to create a tag\n> \"delete\" at the commit marked by master.\n\ngit-tag being a porcelain command (i.e. we do not give a promise to keep\nit set to stone) can be changed with a deprecation announcement period.\nSay starting with Git 2.6 we would put out warnings for upcoming commands:\n\n $ git tag --delete master\n $ echo $?\n # 0 # actually works as of today!\n\n $ git tag delete master\n # Due to the planned switch to command words, this doesn't work.\n # For details see road map at `man git commandwords-roadmaps`\n $ echo $?\n # 128 maybe ?\n\n$ git tag create delete\n\nAnd after a while (maybe 3-5 years, once this version is picked up by\ndebian stable as well as red hat stable)\nwe can change it, so with Git 3.4(?)\n\n $ git tag --delete master\n # --delete is deprecated since 3.4, use `git tag delete` instead\n $ echo $?\n # 128\n\n $ git tag delete master\n # --delete is deprecated since 2.6, use `git tag delete` instead\n $ echo $?\n # 0 # actually works!\n\n>\n> I can't think of an easy way to deprecate the change in behavior over\n> time, which means that making a conversion would require some other as\n> yet unknown way?\n>\n> It may be possible to convert other options based commands, such as\n> how git-branch and git-checkout do things which seem highly unrelated.\n> A good example is how checkout is used to both change branches, as\n> well as can create a branch, and can also checkout a file. The \"reset\"\n> command is used to rewind history, as well as potentially reset *all*\n> files, but it can't be used to reset a single file, and is completely\n> different from revert. Some of these distinctions are ok because it's\n> just no good way to make everything easy.\n>\n> Some of these could be fixed by the command word setup, but as many\n> have mentioned an actual migration plan is difficult.\n>\n> Personally, I don't want to move to the command option \"--status\"\n> format, as I think these aren't really options, and are very much\n> sub-subcommands. I think we should try to push more uses of this\n> style, and try to determine a possible migration path towards using\n> them. Maybe some warts simply aren't worth the effort to fix though.\n>\n> Other issues are tricker to solve, and are result of git exposing more\n> complex functionality and users eventually simply have to learn and\n> understand.\n>\n> Regards,\n> Jake\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"268698","messageId":"CA+P7+xrawC42hm54_8cNYpv51H+LgUF-F4kKQ9W3pcAe+Q2q=Q@mail.gmail.com","threadId":"40171","inReplyTo":"CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-25T22:21:33Z","receivedAt":"2015-08-25T22:21:33Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Aug 25, 2015 at 3:06 PM, Stefan Beller wrote:\n> On Tue, Aug 25, 2015 at 2:49 PM, Jacob Keller wrote:\n>> On Tue, Aug 25, 2015 at 8:13 AM, Junio C Hamano wrote:\n>>> On Tue, Aug 25, 2015 at 1:01 AM, Graeme Geldenhuys wrote:\n>>>>\n>>>> Even though I have worked with Git since 2009, I still have to\n>>>> reference the help to remind me of what parameter to use in certain\n>>>> situation simply because similar tasks differ so much.\n>>>>\n>>>> Maybe we could address this in the next major version of Git? Has\n>>>> anybody else thought about this or started work on this? Or was this\n>>>> discussed before and declined (link?).\n>>>\n>>> http://article.gmane.org/gmane.comp.version-control.git/231478 comes to mind,\n>>> which has been linked from this entry:\n>>>\n>>> Discuss and decide if we want to choose between the \"mode word\" UI\n>>> (e.g. \"git submodule add\") and the \"mode option\" UI (e.g. \"git tag --delete\")\n>>> and standardise on one; if it turns out to be a good idea, devise the migration\n>>> plan to break the backward-compatibility.\n>>>\n>>> in http://git-blame.blogspot.com/p/leftover-bits.html\n>>\n>> I would vote for command words, as this is clean and simple.\n>\n> me too after rereading the arguments in that thread.\n>\n>> The\n>> downside is in converting all the old options based commands, git-tag,\n>> and similar. These commands cannot easily convert because \"valid\"\n>> sequences would become invalid with no easy way to deprecate for\n>> example in the linked gmane above, \"git tag delete master\" can't be a\n>> call to delete master as it is currently a call to create a tag\n>> \"delete\" at the commit marked by master.\n>\n> git-tag being a porcelain command (i.e. we do not give a promise to keep\n> it set to stone) can be changed with a deprecation announcement period.\n> Say starting with Git 2.6 we would put out warnings for upcoming commands:\n>\n> $ git tag --delete master\n> $ echo $?\n> # 0 # actually works as of today!\n>\n> $ git tag delete master\n> # Due to the planned switch to command words, this doesn't work.\n> # For details see road map at `man git commandwords-roadmaps`\n> $ echo $?\n> # 128 maybe ?\n>\n> $ git tag create delete\n>\n> And after a while (maybe 3-5 years, once this version is picked up by\n> debian stable as well as red hat stable)\n> we can change it, so with Git 3.4(?)\n>\n> $ git tag --delete master\n> # --delete is deprecated since 3.4, use `git tag delete` instead\n> $ echo $?\n> # 128\n>\n> $ git tag delete master\n> # --delete is deprecated since 2.6, use `git tag delete` instead\n> $ echo $?\n> # 0 # actually works!\n>\n\n\nThis seems like a possible strategy for converging on command words.\nSo basically, we force all uses of the command words to just fail and\nthen once that's picked up we can migrate to the command words.\n\nRegards,\nJake\n"},{"id":"268705","messageId":"xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com","threadId":"40171","inReplyTo":"CAGZ79kZ6KK0qVtzrxmmsBQqmz-dgamC4f6W0zVTQLcuYi==0fw@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-25T23:43:38Z","receivedAt":"2015-08-25T23:43:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> $ git tag --delete master\n> $ echo $?\n> # 0 # actually works as of today!\n>\n> $ git tag delete master\n> # Due to the planned switch to command words, this doesn't work.\n> # For details see road map at `man git commandwords-roadmaps`\n> $ echo $?\n> # 128 maybe ?\n\nThis is way too aggressive behaviour and is unacceptable as the\nfirst step. The first step of a transition that breaks backward\ncompatibility should warn loudly about a command line that would\nbehave differently in the endgame version (either the command line\nthat will not do anything or do a totally different thing), but\nstill perform the operation asked for the current version.\n\n e.g. \"git tag delete master\" would create a tag named 'delete'\n out of 'master', but tell the user that this will instead delete\n 'master' in future versions of Git. \"git tag create master\"\n would create a tag named 'create' out of 'master', but tell the\n user that this will instead create 'master' out of HEAD in\n future versions of Git.\n\n e.g. \"git tag -d foo\" would delete a tag named 'foo', but tell\n the user that this will have to be spelled 'git tag delete foo'\n in the future versions of Git.\n\nOne thing that I am not enthused about the transition plan is that\n\"git tag delete master\" will *never* be an invalid operation during\nthe transition. When making an operation that used to mean one\nthing to mean something else, a good transition plan should be to\n\n * First warn but do the old thing, and tell users a new way to do\n that in the new world order. At the same time, find the new way\n that used to be an invalid operation in the old world order, and\n implement it.\n\n * Then stop supporting the old thing and support only the new\n thing.\n\nThen during the transition period, while transitioning to the new\nway, people can gradually start using the new way with the new\nsystem, and when they occasionally have to interact with an old\nsystem, the new way will _error out_, because we make sure we find\nthe new way that \"used to be an invalid operation\" when planning the\nwhole transition plan, without causing any harm. And once people\nretrain their finger after 2-3 years, nobody will be hurt if we\ndropped the old way.\n\nI do not see a good way to do such a safe transition with command\nwords approach, *unless* we are going to introduce new commands,\ni.e. \"git list-tag\", \"git create-tag\", etc.\n\nSo don't hold your breath. What you two are discussing is way too\nuncooked for 2.6 timeframe.\n"},{"id":"268707","messageId":"CAE1pOi3e8KS9x5yD7CZLESvhXy1oXmQEgUnEFjww7L6JOdZ1Jg@mail.gmail.com","threadId":"40171","inReplyTo":"xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com","subject":"Re: Git's inconsistent command line options","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2015-08-26T01:30:18Z","receivedAt":"2015-08-26T01:30:18Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"On 25 August 2015 at 16:43, Junio C Hamano wrote:\n> I do not see a good way to do such a safe transition with command\n> words approach, *unless* we are going to introduce new commands,\n> i.e. \"git list-tag\", \"git create-tag\", etc.\n\nPerhaps we could introduce a more explicit notion (in .git/config) of\na Git API version (or, perhaps more accurate, a Git CLI API version)?\n\nThe default would be 2 (since we're already at Git 2.x). Git commands\ncould check for this setting and abort/introduce/prevent/change\nbehaviour/functionality as appropriate. During Git 2.x the API 2 would\nbe the default but users could explicitly request 3 in preparation of\nGit 3.x. (With the knowledge that API 3 would still be [to some extent\nat least] in flux.) API 2 could start warning about future changes\nwhere appropriate. With the introduction of Git 3.x, the default would\nbecome API 3 but users could still request API 2. Then for Git 4.x the\ndefault would go to 4, with an option to request 3 but 2 would no\nlonger be supported (and all code supporting API 2 could be removed).\n\nI think that from a user's point of view this could work quite well.\nObviously, (worst case scenario) Git commands might have to support up\nto 3 APIs at the same time (previous [2], current [3], and future [4]\nfor Git 3.x) so from a code maintenance POV it would certainly\nintroduce complexity and probably some duplication of code. I'm\nhopeful it would be limited to CL argument processing but I suspect\nthat when Git code calls other Git code (especially in the Bash based\ncommands) there might be some more complexity there.\n\nWould something like that be feasible?\n"},{"id":"268712","messageId":"CA+P7+xoQnq-nCP=_Wtfh39fxxwTvEo+m-=o7fcmrdyaBBfbt8A@mail.gmail.com","threadId":"40171","inReplyTo":"xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-26T04:09:41Z","receivedAt":"2015-08-26T04:09:41Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Aug 25, 2015 at 4:43 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> $ git tag --delete master\n>> $ echo $?\n>> # 0 # actually works as of today!\n>>\n>> $ git tag delete master\n>> # Due to the planned switch to command words, this doesn't work.\n>> # For details see road map at `man git commandwords-roadmaps`\n>> $ echo $?\n>> # 128 maybe ?\n>\n> This is way too aggressive behaviour and is unacceptable as the\n> first step. The first step of a transition that breaks backward\n> compatibility should warn loudly about a command line that would\n> behave differently in the endgame version (either the command line\n> that will not do anything or do a totally different thing), but\n> still perform the operation asked for the current version.\n>\n\n\n> e.g. \"git tag delete master\" would create a tag named 'delete'\n> out of 'master', but tell the user that this will instead delete\n> 'master' in future versions of Git. \"git tag create master\"\n> would create a tag named 'create' out of 'master', but tell the\n> user that this will instead create 'master' out of HEAD in\n> future versions of Git.\n>\n> e.g. \"git tag -d foo\" would delete a tag named 'foo', but tell\n> the user that this will have to be spelled 'git tag delete foo'\n> in the future versions of Git.\n>\n> One thing that I am not enthused about the transition plan is that\n> \"git tag delete master\" will *never* be an invalid operation during\n> the transition. When making an operation that used to mean one\n> thing to mean something else, a good transition plan should be to\n>\n> * First warn but do the old thing, and tell users a new way to do\n> that in the new world order. At the same time, find the new way\n> that used to be an invalid operation in the old world order, and\n> implement it.\n>\n> * Then stop supporting the old thing and support only the new\n> thing.\n>\n> Then during the transition period, while transitioning to the new\n> way, people can gradually start using the new way with the new\n> system, and when they occasionally have to interact with an old\n> system, the new way will _error out_, because we make sure we find\n> the new way that \"used to be an invalid operation\" when planning the\n> whole transition plan, without causing any harm. And once people\n> retrain their finger after 2-3 years, nobody will be hurt if we\n> dropped the old way.\n>\n> I do not see a good way to do such a safe transition with command\n> words approach, *unless* we are going to introduce new commands,\n> i.e. \"git list-tag\", \"git create-tag\", etc.\n>\n> So don't hold your breath. What you two are discussing is way too\n> uncooked for 2.6 timeframe.\n>\n>\n>\n\nYa, there isn't really a way to make it work, because we can't exactly\nstop supporting \"git tag create master\" by turning it into a no-op,\nbecause there is no equivalent tag option that would work for now.\nSince there is no alternative syntax for \"create\" I think this is the\nissue. One way might be to use the -- splitter to say,\n\n\"if you really mean to create a tag named create, use\n\ngit tag -- create master\n\nSo we'd do:\n\n- step 1 -\ngit tag create master\n# warn that this will change behavior in the future and they must\nexplicitely pass -- before it\n\n- step 2 -\nbreak create, but don't add anything new. If user really needs it,\nthey can pass \"git tag -- create master\" as per above warning, but\nkeep warning on \"git tag create master\" to say they must be explicit.\n\n- step 3 -\n\nimplement git tag create master to actually perform tag creation\n\nI think this might work, as long as \"git tag -- create master\" is acceptable?\n\nthen, eventually we can make it so that \"git tag\" doesn't mean create\nby default if we ever wanted?\n\nHow does this sound? By the way, this wouldn't be necessarily done\nover 2.6 or even over only a single release, I think the time frame\nwould have to be fairly long.\n\nThe downside is that there is no point where new and old syntax are\nusable at the same time... but I don't think that will ever be the\ncase. We'd need to way the concern of whether this is actually worth\ndoing to streamline the overall feel at some point in the future or we\njust live with the warts.\n\nRegards,\nJake\n"},{"id":"268715","messageId":"877foief6z.fsf@igel.home","threadId":"40171","inReplyTo":"CA+P7+xoQnq-nCP=_Wtfh39fxxwTvEo+m-=o7fcmrdyaBBfbt8A@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2015-08-26T06:28:36Z","receivedAt":"2015-08-26T06:28:36Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Jacob Keller writes:\n\n> \"if you really mean to create a tag named create, use\n>\n> git tag -- create master\n\nIn all other uses of -- refs must be put on the *left* side.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"268717","messageId":"CA+P7+xpMnRhNd843_w-RcvH=6eB52AhhNJ+dQWogRBWggyjtvA@mail.gmail.com","threadId":"40171","inReplyTo":"877foief6z.fsf@igel.home","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-26T06:33:17Z","receivedAt":"2015-08-26T06:33:17Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Aug 25, 2015 at 11:28 PM, Andreas Schwab wrote:\n> Jacob Keller writes:\n>\n>> \"if you really mean to create a tag named create, use\n>>\n>> git tag -- create master\n>\n> In all other uses of -- refs must be put on the *left* side.\n>\n> Andreas.\n>\n\nOops that wouldn't be consistent then. Normally \"--\" is used to\nseparate options from non-options arguments, but we usually use it to\nseparate refs from non-refs.\n\nGuess that sort of ruins this particular strategy.\n\nRegards,\nJake\n"},{"id":"268740","messageId":"xmqqio822atc.fsf@gitster.dls.corp.google.com","threadId":"40171","inReplyTo":"CAE1pOi3e8KS9x5yD7CZLESvhXy1oXmQEgUnEFjww7L6JOdZ1Jg@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-26T17:56:15Z","receivedAt":"2015-08-26T17:56:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hilco Wijbenga writes:\n\n> On 25 August 2015 at 16:43, Junio C Hamano wrote:\n>> I do not see a good way to do such a safe transition with command\n>> words approach, *unless* we are going to introduce new commands,\n>> i.e. \"git list-tag\", \"git create-tag\", etc.\n>\n> Perhaps we could introduce a more explicit notion (in .git/config) of\n> a Git API version (or, perhaps more accurate, a Git CLI API version)?\n> ...\n> I think that from a user's point of view this could work quite well.\n> Obviously, (worst case scenario) Git commands might have to support up\n> to 3 APIs at the same time (previous [2], current [3], and future [4]\n> for Git 3.x) so from a code maintenance POV it would certainly\n> introduce complexity and probably some duplication of code. I'm\n> hopeful it would be limited to CL argument processing but I suspect\n> that when Git code calls other Git code (especially in the Bash based\n> commands) there might be some more complexity there.\n>\n> Would something like that be feasible?\n\nA bigger issue you need to think about is what to do to scripts\npeople have. Your approach forces them to update a script to delete\na tag and do something else to say something silly like this:\n\n\t#!/bin/sh\n # My Script\n\tcase \"$(git config core.apiVersion)\" in\n \"\" | 2)\n\t\tgit tag -d \"$1\"\n do something else on \"$1\" using v2 API\n ;;\n\n 3)\n\t\tgit tag delete \"$1\"\n do something else on \"$1\" using v3 API\n ;;\n\n\t*)\n \techo >&2 \"sorry, I do not know what Git you are using\"\n\t\texit 1\n ;;\n\tesac\n\nSo, it may be feasible to implement, but I do not think it would be\nuseful to do so.\n\nInstead, if you really want to invent the multi-version world, you\nwould rather want to have something more like this:\n\n\t#!/bin/sh\n # My Script\n\tGIT_API_VERSION=2\n\texport GIT_API_VERSION\n\n\tgit tag -d \"$1\"\n do something else on \"$1\" using v2 API\n\nBut notice that I said \"if you really want to\". I personally think\nit is a road to madness.\n"},{"id":"268741","messageId":"CA+P7+xoV=NZvcUyqbdOpjcD1ykrpU7zrWB4JDVMSdBVC7EHEgw@mail.gmail.com","threadId":"40171","inReplyTo":"xmqqio822atc.fsf@gitster.dls.corp.google.com","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-26T18:10:42Z","receivedAt":"2015-08-26T18:10:42Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano wrote:\n> But notice that I said \"if you really want to\". I personally think\n> it is a road to madness.\n\nAgreed. I don't believe in command line API here. I think we'd need a\nbetter solution.\n\nMy gut says: Live with the warts on old commands and try to make\npeople use command words for new commands.\n"},{"id":"268756","messageId":"xmqq1tep3he1.fsf@gitster.dls.corp.google.com","threadId":"40171","inReplyTo":"CA+P7+xoV=NZvcUyqbdOpjcD1ykrpU7zrWB4JDVMSdBVC7EHEgw@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-08-26T20:48:54Z","receivedAt":"2015-08-26T20:48:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller writes:\n\n> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano wrote:\n>> But notice that I said \"if you really want to\". I personally think\n>> it is a road to madness.\n>\n> Agreed. I don't believe in command line API here. I think we'd need a\n> better solution.\n>\n> My gut says: Live with the warts on old commands and try to make\n> people use command words for new commands.\n\nA transition to make everybody to use subsubcommands (thereby\nchanging what \"git tag delete master\" means) is impossible in\npractice. On the other hand, a transition to make everybody use\ncommand mode options (thereby allowing \"git worktree list\" to be\nalso spelled as \"git worktree --list\") _is_ possible.\n\nHas anybody created a handy catalog of Git commands with subcommands\nand command mode options? If we see such a list and replace the\ncolumn of subcommands with command mode options, we might find that\nsuch a \"command mode option only\" world a pleasant future for us to\nlive in, or an unpleasant one that we have to keep typing two extra\ndashes all the time. I cannot tell offhand.\n"},{"id":"268765","messageId":"500FC504AB174A98B31CD8BEFCDDCFAC@PhilipOakley","threadId":"40171","inReplyTo":"CA+P7+xoV=NZvcUyqbdOpjcD1ykrpU7zrWB4JDVMSdBVC7EHEgw@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2015-08-26T22:52:19Z","receivedAt":"2015-08-26T22:52:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jacob Keller\" \n> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano \n> wrote:\n>> But notice that I said \"if you really want to\". I personally think\n>> it is a road to madness.\n>\n> Agreed. I don't believe in command line API here. I think we'd need a\n> better solution.\n>\n> My gut says: Live with the warts on old commands and try to make\n> people use command words for new commands.\n> --\nAgreed. However Graeme's original question also said \"I can supply a \nmore extensive list if needed\", and \"I still have to reference the help \nto remind me of what parameter to use in certain situation\", which \nsuggests that one option is to capture that list within some part of the \ndocumentation, especially if Graeme already has an easy to read layout.\n\nIf it could be part of the documenation, where should it go - gitcli or \nperhaps it's own guide (`git help -g` and friends)?\n\n--\n\nPhilip\n"},{"id":"268766","messageId":"CA+P7+xqYMHfMuBKtGK_p8mwbLjEJWN80i1oDyCdJ_0iVZPmhaQ@mail.gmail.com","threadId":"40171","inReplyTo":"500FC504AB174A98B31CD8BEFCDDCFAC@PhilipOakley","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-26T23:02:21Z","receivedAt":"2015-08-26T23:02:21Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley wrote:\n> From: \"Jacob Keller\" \n>>\n>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano \n>> wrote:\n>>>\n>>> But notice that I said \"if you really want to\". I personally think\n>>> it is a road to madness.\n>>\n>>\n>> Agreed. I don't believe in command line API here. I think we'd need a\n>> better solution.\n>>\n>> My gut says: Live with the warts on old commands and try to make\n>> people use command words for new commands.\n>> --\n>\n> Agreed. However Graeme's original question also said \"I can supply a more\n> extensive list if needed\", and \"I still have to reference the help to remind\n> me of what parameter to use in certain situation\", which suggests that one\n> option is to capture that list within some part of the documentation,\n> especially if Graeme already has an easy to read layout.\n>\n> If it could be part of the documenation, where should it go - gitcli or\n> perhaps it's own guide (`git help -g` and friends)?\n>\n\nI hope to spend some time investigating this in the near future.\nPersonally I feel that command names make more sense than options\nsince they are essentially non-options, and it helps separate\nlogically related but non-equivalent operations more easily.\n\nThe confusion that results from git-checkout, and git-branch has\ncaught more than a few new people at $dayjob.\n\nRegards,\nJake\n"},{"id":"268767","messageId":"CA+P7+xrzU=n65sVkHH9O5v7QjC=vKkQDQy5u4XVby19T9O98Pw@mail.gmail.com","threadId":"40171","inReplyTo":"CA+P7+xqYMHfMuBKtGK_p8mwbLjEJWN80i1oDyCdJ_0iVZPmhaQ@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2015-08-26T23:03:31Z","receivedAt":"2015-08-26T23:03:31Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Aug 26, 2015 at 4:02 PM, Jacob Keller wrote:\n> On Wed, Aug 26, 2015 at 3:52 PM, Philip Oakley wrote:\n>> From: \"Jacob Keller\" \n>>>\n>>> On Wed, Aug 26, 2015 at 10:56 AM, Junio C Hamano \n>>> wrote:\n>>>>\n>>>> But notice that I said \"if you really want to\". I personally think\n>>>> it is a road to madness.\n>>>\n>>>\n>>> Agreed. I don't believe in command line API here. I think we'd need a\n>>> better solution.\n>>>\n>>> My gut says: Live with the warts on old commands and try to make\n>>> people use command words for new commands.\n>>> --\n>>\n>> Agreed. However Graeme's original question also said \"I can supply a more\n>> extensive list if needed\", and \"I still have to reference the help to remind\n>> me of what parameter to use in certain situation\", which suggests that one\n>> option is to capture that list within some part of the documentation,\n>> especially if Graeme already has an easy to read layout.\n>>\n>> If it could be part of the documenation, where should it go - gitcli or\n>> perhaps it's own guide (`git help -g` and friends)?\n>>\n>\n> I hope to spend some time investigating this in the near future.\n> Personally I feel that command names make more sense than options\n> since they are essentially non-options, and it helps separate\n> logically related but non-equivalent operations more easily.\n>\n> The confusion that results from git-checkout, and git-branch has\n> caught more than a few new people at $dayjob.\n>\n> Regards,\n> Jake\n\nThat being said, use of \"--create\" or so forth really isn't that\nbothersome so maybe the gains outway the cons here.\n\nRegards,\nJake\n"},{"id":"268977","messageId":"CACsJy8D3J6RhtPPtSvtWfOb8BapaX2-52M5_fE36psQPB_oQsQ@mail.gmail.com","threadId":"40171","inReplyTo":"xmqqa8tfvsr9.fsf@gitster.dls.corp.google.com","subject":"Re: Git's inconsistent command line options","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-08-31T10:10:29Z","receivedAt":"2015-08-31T10:10:29Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Aug 26, 2015 at 6:43 AM, Junio C Hamano wrote:\n> ...\n>\n> I do not see a good way to do such a safe transition with command\n> words approach, *unless* we are going to introduce new commands,\n> i.e. \"git list-tag\", \"git create-tag\", etc.\n\nI'm probably shot down for this. But could we go with a clean plate\nand create a new command prefix (something like git-next, git2, or\ngt...)? We could then redesign the entire UI without worrying about\nbackward compatibility. At some point we can start to deprecate \"git\"\nand encourage to use the new command prefix only. Of course somebody\nhas to go over all the commands and options to propose some consistent\nUI, then more discussions and coding so it could likely follow the\npath of pack v4..\n-- \nDuy\n"},{"id":"268994","messageId":"20150831102558.1514e5f7@anarchist.wooz.org","threadId":"40171","inReplyTo":"CACsJy8D3J6RhtPPtSvtWfOb8BapaX2-52M5_fE36psQPB_oQsQ@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Barry Warsaw","fromEmail":"barry@python.org","sentAt":"2015-08-31T14:25:58Z","receivedAt":"2015-08-31T14:25:58Z","isPatch":false,"sender":{"key":"barry@python.org","avatar":"https://gravatar.com/avatar/c1f9952e8b0ee2ae199ba65f58cc2d3e0b71f3aa1006cadbee182ef74425d88b?d=mp&s=160"},"body":"On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote:\n\n>I'm probably shot down for this. But could we go with a clean plate\n>and create a new command prefix (something like git-next, git2, or\n>gt...)? We could then redesign the entire UI without worrying about\n>backward compatibility. At some point we can start to deprecate \"git\"\n>and encourage to use the new command prefix only. Of course somebody\n>has to go over all the commands and options to propose some consistent\n>UI, then more discussions and coding so it could likely follow the\n>path of pack v4..\n\n`git` itself could also be a thin wrapper which consulted a configuration\nvariable to see which version of the ui to expose.\n\n\"All problems in computer science can be solved by another level of\nindirection\"\n\nCheers,\n-Barry\n\n"},{"id":"269086","messageId":"20150901092834.GA10706@gmail.com","threadId":"40171","inReplyTo":"20150831102558.1514e5f7@anarchist.wooz.org","subject":"Re: Git's inconsistent command line options","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2015-09-01T09:28:34Z","receivedAt":"2015-09-01T09:28:34Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Aug 31, 2015 at 10:25:58AM -0400, Barry Warsaw wrote:\n> On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote:\n> \n> >I'm probably shot down for this. But could we go with a clean plate\n> >and create a new command prefix (something like git-next, git2, or\n> >gt...)? We could then redesign the entire UI without worrying about\n> >backward compatibility. At some point we can start to deprecate \"git\"\n> >and encourage to use the new command prefix only. Of course somebody\n> >has to go over all the commands and options to propose some consistent\n> >UI, then more discussions and coding so it could likely follow the\n> >path of pack v4..\n> \n> `git` itself could also be a thin wrapper which consulted a configuration\n> variable to see which version of the ui to expose.\n> \n> \"All problems in computer science can be solved by another level of\n> indirection\"\n\nExcept for poor performance, simplicity, and bad ideas.\n\nThe Git project does not break backwards compatibility.\nLet's let Python3 serve as a good lesson on why not to do that! ;-p\n\nWhile a script writer could write, \"git -c core.cliversion=1 ...\",\nno one does that, no one wants to do that, and it just seems\nlike a bad idea that's best left unexplored.\n\nThe only idea in this thread that's user-friendly would be a new\nGit that still supported the entirety of the existing,\nperfectly-good CLI interface and *also* accepted some new\n\"consistent\" user interface.\n\nOtherwise, this entire thread seems like a big non-issue.\nThe existing CLI hasn't hurt adoption, and tossing a config\noption at it only makes it worse. The best config is no config.\n\nThere really are ony a few corner cases that would need to be\ntweaked to support --named-subcommands style, and after that is\ndone, is Git really that much easier to use?\n\nMaybe a little bit, but not enough that warrants breaking\nexisting scripts IMO.\n---\nDavid\n"},{"id":"269092","messageId":"20150901101924.6c350012@anarchist.wooz.org","threadId":"40171","inReplyTo":"20150901092834.GA10706@gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Barry Warsaw","fromEmail":"barry@python.org","sentAt":"2015-09-01T14:19:24Z","receivedAt":"2015-09-01T14:19:24Z","isPatch":false,"sender":{"key":"barry@python.org","avatar":"https://gravatar.com/avatar/c1f9952e8b0ee2ae199ba65f58cc2d3e0b71f3aa1006cadbee182ef74425d88b?d=mp&s=160"},"body":"On Sep 01, 2015, at 02:28 AM, David Aguilar wrote:\n\n>While a script writer could write, \"git -c core.cliversion=1 ...\",\n>no one does that, no one wants to do that, and it just seems\n>like a bad idea that's best left unexplored.\n\nSure, no one will do that from the command line, but I don't think people\ngenerally change their preferences that often. Much more likely is that\nthey'll `git config` a more permanent choice for their shell usage and then\njust use straight up \"git\" with the new ui. -c would be reserved for scripts\nwhich hard code a particular ui.\n\n>Otherwise, this entire thread seems like a big non-issue. The existing CLI\n>hasn't hurt adoption...\n\nA significant factor driving git adoption is network effects. That's highly\nmotivating to overcome discomfort or confusion with the cli. Once you've lost\nyour beginner's mind, you are much less aware of the cli inconsistencies and\ndisconnects from other vcses. The latter might not affect new users whose\nonly experience with vcses is git, but it presents a steeper learning curve\nfor folks migrating from other tools.\n\n>...and tossing a config option at it only makes it worse. The best config is\n>no config.\n\ngit already has no shortage of configuration options. ;)\n\nCheers,\n-Barry\n"},{"id":"269102","messageId":"xmqq37yyt7k8.fsf@gitster.mtv.corp.google.com","threadId":"40171","inReplyTo":"20150901101924.6c350012@anarchist.wooz.org","subject":"Re: Git's inconsistent command line options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-01T16:42:31Z","receivedAt":"2015-09-01T16:42:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"(Administrivia) please do not cull CC list when replying.\n\nBarry Warsaw writes:\n\n> On Sep 01, 2015, at 02:28 AM, David Aguilar wrote:\n>\n>>While a script writer could write, \"git -c core.cliversion=1 ...\",\n>>no one does that, no one wants to do that, and it just seems\n>>like a bad idea that's best left unexplored.\n>\n> Sure, no one will do that from the command line, but I don't think people\n> generally change their preferences that often. Much more likely is that\n> they'll `git config` a more permanent choice for their shell usage and then\n> just use straight up \"git\" with the new ui. -c would be reserved for scripts\n> which hard code a particular ui.\n\nThat way, you are forcing all the existing scripts to be updated to\nsay \"git -c ...\" for _all_ invocations of Git they have, aren't you?\n\nThat is simply unworkable.\n\nBy the way, you can review what has already been said in this\ndiscussion here:\n\n http://thread.gmane.org/gmane.comp.version-control.git/276509/focus=276589\n"},{"id":"269115","messageId":"20150901135018.70240193@limelight.wooz.org","threadId":"40171","inReplyTo":"xmqq37yyt7k8.fsf@gitster.mtv.corp.google.com","subject":"Re: Git's inconsistent command line options","fromName":"Barry Warsaw","fromEmail":"barry@python.org","sentAt":"2015-09-01T17:50:18Z","receivedAt":"2015-09-01T17:50:18Z","isPatch":false,"sender":{"key":"barry@python.org","avatar":"https://gravatar.com/avatar/c1f9952e8b0ee2ae199ba65f58cc2d3e0b71f3aa1006cadbee182ef74425d88b?d=mp&s=160"},"body":"On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote:\n\n>That way, you are forcing all the existing scripts to be updated to\n>say \"git -c ...\" for _all_ invocations of Git they have, aren't you?\n\nNo, why? If the default value enables the current ui, then no scripts need\nchanging. Users can enable the new ui for their own benefit at their own\npace. If you eventually want to make the new ui the default, provide a\nsufficient transition period.\n\nCheers,\n-Barry\n"},{"id":"269116","messageId":"CAGZ79ka4+a_eyha=xCrQFBdLzgbT3ws1Jq7Q=WJw45Ob6bFFug@mail.gmail.com","threadId":"40171","inReplyTo":"20150901135018.70240193@limelight.wooz.org","subject":"Re: Git's inconsistent command line options","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-09-01T17:56:03Z","receivedAt":"2015-09-01T17:56:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Sep 1, 2015 at 10:50 AM, Barry Warsaw wrote:\n> On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote:\n>\n>>That way, you are forcing all the existing scripts to be updated to\n>>say \"git -c ...\" for _all_ invocations of Git they have, aren't you?\n>\n> No, why? If the default value enables the current ui, then no scripts need\n> changing. Users can enable the new ui for their own benefit at their own\n> pace. If you eventually want to make the new ui the default, provide a\n> sufficient transition period.\n>\n> Cheers,\n> -Barry\n\nSo say I am a user who wants to take the new command set. And as I am lazy to\ntype it all the time I just do:\n\n $ git config --global command-version 2\n\nNow I have all the new fancy stuff when I type it directly into the terminal.\nBut when I run one of the old scripts my coworker gave me (which is used to\nthe old notion), it must adhere to the old command world. How do you now figure\nout if this is interactive or script?\n"},{"id":"269647","messageId":"55EFFF11.8000500@drmicha.warpmail.net","threadId":"40171","inReplyTo":"20150901092834.GA10706@gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-09-09T09:42:41Z","receivedAt":"2015-09-09T09:42:41Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"David Aguilar venit, vidit, dixit 01.09.2015 11:28:\n> On Mon, Aug 31, 2015 at 10:25:58AM -0400, Barry Warsaw wrote:\n>> On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote:\n>>\n>>> I'm probably shot down for this. But could we go with a clean plate\n>>> and create a new command prefix (something like git-next, git2, or\n>>> gt...)? We could then redesign the entire UI without worrying about\n>>> backward compatibility. At some point we can start to deprecate \"git\"\n>>> and encourage to use the new command prefix only. Of course somebody\n>>> has to go over all the commands and options to propose some consistent\n>>> UI, then more discussions and coding so it could likely follow the\n>>> path of pack v4..\n>>\n>> `git` itself could also be a thin wrapper which consulted a configuration\n>> variable to see which version of the ui to expose.\n>>\n>> \"All problems in computer science can be solved by another level of\n>> indirection\"\n> \n> Except for poor performance, simplicity, and bad ideas.\n> \n> The Git project does not break backwards compatibility.\n> Let's let Python3 serve as a good lesson on why not to do that! ;-p\n> \n> While a script writer could write, \"git -c core.cliversion=1 ...\",\n> no one does that, no one wants to do that, and it just seems\n> like a bad idea that's best left unexplored.\n> \n> The only idea in this thread that's user-friendly would be a new\n> Git that still supported the entirety of the existing,\n> perfectly-good CLI interface and *also* accepted some new\n> \"consistent\" user interface.\n\nGive it a break. If Git had a perfectly-good CLI interface we didn't\nhave any complaints. But we have many well-founded complaints about\ninconsistencies, such as short-options (-n), subsubcommands etc.\n\n> Otherwise, this entire thread seems like a big non-issue.\n> The existing CLI hasn't hurt adoption, and tossing a config\n> option at it only makes it worse. The best config is no config.\n\nI certainly agree with you on that. Unfortunately, we've seen quite an\nincrease of config options whose sole purpose is changing default\noptions for some commands.\n\n> There really are ony a few corner cases that would need to be\n> tweaked to support --named-subcommands style, and after that is\n> done, is Git really that much easier to use?\n> \n> Maybe a little bit, but not enough that warrants breaking\n> existing scripts IMO.\n> ---\n> David\n\nWell, it may actually hurt to reach some substantial improvements. It\nmay actually be worth it if it ends constant suffering from how it is\nnow. Those are the points that we have to weigh carefully. Simply\nresisting change won't take us anywhere.\n\nMichael\n"},{"id":"269648","messageId":"55EFFF1E.1050409@drmicha.warpmail.net","threadId":"40171","inReplyTo":"CAGZ79ka4+a_eyha=xCrQFBdLzgbT3ws1Jq7Q=WJw45Ob6bFFug@mail.gmail.com","subject":"Re: Git's inconsistent command line options","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-09-09T09:42:54Z","receivedAt":"2015-09-09T09:42:54Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Stefan Beller venit, vidit, dixit 01.09.2015 19:56:\n> On Tue, Sep 1, 2015 at 10:50 AM, Barry Warsaw wrote:\n>> On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote:\n>>\n>>> That way, you are forcing all the existing scripts to be updated to\n>>> say \"git -c ...\" for _all_ invocations of Git they have, aren't you?\n>>\n>> No, why? If the default value enables the current ui, then no scripts need\n>> changing. Users can enable the new ui for their own benefit at their own\n>> pace. If you eventually want to make the new ui the default, provide a\n>> sufficient transition period.\n>>\n>> Cheers,\n>> -Barry\n> \n> So say I am a user who wants to take the new command set. And as I am lazy to\n> type it all the time I just do:\n> \n> $ git config --global command-version 2\n> \n> Now I have all the new fancy stuff when I type it directly into the terminal.\n> But when I run one of the old scripts my coworker gave me (which is used to\n> the old notion), it must adhere to the old command world. How do you now figure\n> out if this is interactive or script?\n\nYou can't. We have that exact same problem already with the recent\noption-overriding config bloat. It needs to be solved sooner or later\nanyways, by introducing some sort of \"mode\" (interactive vs. scripting),\nsince while in principle we have a separation between porcelain and\nplumbing commands, we don't have, say, a plumbing version of \"git tag\"\nand take that as an excuse^Wreason for any change to the porcelain\ncommand \"git tag\". (You can freely interchange the roles here.)\n\nReally, that porcelain-plumbing separation that's often mentioned is\nmore wishful thinking than actual reality, at least no complete reality,\nor else we wouldn't even have any backward compatibility problem to\nsolve here.\n\nSo, UI rework or not, we should think about making that promise real: a\nclear separation between a stable scripting interface and an evolving\nuser interface. Two possible ways are:\n\n- separate commands, such as git-log vs. git-rev-list\n- separate modes for the same commands\n\nWe use both of them (\"interactive\" detection for some default settings),\nbut partially only.\n\nMichael\n"}]}