{"thread":{"id":"31764","subject":"git checkout error","startedAt":"2012-10-09T07:41:38Z","lastAt":"2012-10-10T08:52:11Z","messageCount":8,"participants":["Angelo Borsotti","Andreas Schwab","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200822","messageId":"CAB9Jk9DUEL_J3MmH_4k7NC82m+crpCf1r3NS3gQBMZy+kvY3-A@mail.gmail.com","threadId":"31764","inReplyTo":null,"subject":"git checkout error","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-09T07:41:38Z","receivedAt":"2012-10-09T07:41:38Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hello,\n\nthe man page of git checkout in the synopsis does not mention the\n--track and --no-track options.\nHowever, in the description below, it states that they are allowed.\nIt does not say that there is a specific ordering in which they must\nbe specified.\n\nIf they are specified after -b, the command seems to behave as if -b\nwas not specified, e.g.:\n\n$ git checkout -b --no-track topic remotes/origin/master\nfatal: git checkout: updating paths is incompatible with switching branches.\n\nwhile if they are specified before -b the command behaves properly, e.g.\n\n$ git checkout --no-track -b topic remotes/origin/master\nSwitched to a new branch 'topic'\n\nIf this is the intended syntax, the synopsis should replace:\n\n     git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]\n\nby;\n\n     git checkout [-q] [-f] [-m] [[--orphan] <new_branch>] [<start_point>]\n     git checkout [-q] [-f] [-m] [ [--track|--no-track](-b|-B)\n<new_branch>] [<start_point>]\n\n-Angelo\n"},{"id":"200826","messageId":"m2lifg7zsj.fsf@igel.home","threadId":"31764","inReplyTo":"CAB9Jk9DUEL_J3MmH_4k7NC82m+crpCf1r3NS3gQBMZy+kvY3-A@mail.gmail.com","subject":"Re: git checkout error","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-10-09T09:36:12Z","receivedAt":"2012-10-09T09:36:12Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Angelo Borsotti <angelo.borsotti@gmail.com> writes:\n\n> If they are specified after -b, the command seems to behave as if -b\n> was not specified, e.g.:\n>\n> $ git checkout -b --no-track topic remotes/origin/master\n\n-b requires an argument <new_branch>, which you specify as --no-track\nhere.  <start_point> is topic, and the rest is interpreted as <paths>.\n\n> fatal: git checkout: updating paths is incompatible with switching branches.\n\nThis error is detected before validating <new_branch>.\n\n> while if they are specified before -b the command behaves properly, e.g.\n>\n> $ git checkout --no-track -b topic remotes/origin/master\n> Switched to a new branch 'topic'\n\nYou can also specify --no-track after -b (and its argument):\n\n$ git checkout -b topic --no-track remotes/origin/master\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":"200849","messageId":"7vzk3vfs2m.fsf@alter.siamese.dyndns.org","threadId":"31764","inReplyTo":"m2lifg7zsj.fsf@igel.home","subject":"Re: git checkout error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-09T17:55:45Z","receivedAt":"2012-10-09T17:55:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab <schwab@linux-m68k.org> writes:\n\n> Angelo Borsotti <angelo.borsotti@gmail.com> writes:\n>\n>> If they are specified after -b, the command seems to behave as if -b\n>> was not specified, e.g.:\n>>\n>> $ git checkout -b --no-track topic remotes/origin/master\n>\n> -b requires an argument <new_branch>, which you specify as --no-track\n> here.  <start_point> is topic, and the rest is interpreted as <paths>.\n>\n>> fatal: git checkout: updating paths is incompatible with switching branches.\n>\n> This error is detected before validating <new_branch>.\n>\n>> while if they are specified before -b the command behaves properly, e.g.\n>>\n>> $ git checkout --no-track -b topic remotes/origin/master\n>> Switched to a new branch 'topic'\n>\n> You can also specify --no-track after -b (and its argument):\n>\n> $ git checkout -b topic --no-track remotes/origin/master\n\nIsn't this \"asked and answered\" recently with this thread?\n\n    http://thread.gmane.org/gmane.comp.version-control.git/204397\n"},{"id":"200867","messageId":"CAB9Jk9CZ8d=8ugYs7XHXs84Kj9xJmTHZyZ2J0hU66OBS7YDZTg@mail.gmail.com","threadId":"31764","inReplyTo":"m2lifg7zsj.fsf@igel.home","subject":"Re: git checkout error","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-09T23:25:59Z","receivedAt":"2012-10-09T23:25:59Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Andreas,\n\n>\n> -b requires an argument <new_branch>, which you specify as --no-track\n> here.  <start_point> is topic, and the rest is interpreted as <paths>.\n>\nThe man page describes --track and --no-track as \"options\". This is why a\nreader thinks that they can be specified in any order.\nIt is also very counter-intuitive to think that --no-track is <new_branch> and\n<start_point> is topic. This is certainly not what the command does with\nthese data because it creates a new branch whose name is <new_branch> and not\n--no-track.\n\nI proposed a small change that clarifies the syntax, but if you prefer\nto keep it obscure ...\n\n-Angelo\n"},{"id":"200869","messageId":"7v626jdx8f.fsf@alter.siamese.dyndns.org","threadId":"31764","inReplyTo":"CAB9Jk9CZ8d=8ugYs7XHXs84Kj9xJmTHZyZ2J0hU66OBS7YDZTg@mail.gmail.com","subject":"Re: git checkout error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-09T23:47:12Z","receivedAt":"2012-10-09T23:47:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angelo Borsotti <angelo.borsotti@gmail.com> writes:\n\n> The man page describes --track and --no-track as \"options\". \n\nBut the problem you observed is *not* about --track or --no-track.\nIt is about the \"-b <branchname>\" option.\n\nYou used the -b option that requires an argument, and as that\nargument, you gave a string \"--no-track\", as if you wanted to create\na branch whose name is \"--no-track\".  After these words on the\ncommand line are understood, there are two other arguments left on\nthe command line, which is an syntax error as far as \"git checkout\"\nis concerned.\n\nAgain, this is asked-and-answered recently, and \n\n    http://thread.gmane.org/gmane.comp.version-control.git/204397\n\nhas resulted in a leading to b6312c2 (checkout: reorder option\nhandling, 2012-08-30), which is in v1.8.0-rc0 and onwards.  You\nshould get an error message that is a lot less confusing:\n\n    $ git checkout -b --no-track topic remotes/origin/master\n    fatal: '--no-track' is not a valid branch name.\n"},{"id":"200881","messageId":"CAB9Jk9AFnauxX0dk8LfpBkpGDSWpWhqnzVew1Eo51K+qEA680A@mail.gmail.com","threadId":"31764","inReplyTo":"7v626jdx8f.fsf@alter.siamese.dyndns.org","subject":"Re: git checkout error","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-10T07:02:30Z","receivedAt":"2012-10-10T07:02:30Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Junio,\n\ngiving the user a better error message is certainly an improvement.\nBut would not be another improvement to describe better the command syntax\nso as to help the user write the command right in the first place?\nAfter all, what is the syntax section in commands for?\nIf I had seen in the syntax:\n\n     git checkout [-q] [-f] [-m] [ [--track|--no-track](-b|-B)\n<new_branch>] [<start_point>]\n\nI would have written the command correctly, and not even stumbled on a\nmisleading\nerror message.\nNote that the above syntax is exactly what the command must look like.\nThe syntax is mostly a description of the form of command for the\nuser. Internally, the\nimplementer can use it or can even use a different one (e.g. a more\nlenient one and\ndetect errors at the semantic level instead). But here what matters is\nnot how the\ncommand is implemented, but how the user has to form it.\nWhy it is so difficult to convince people to make documentation better?\n\n-Angelo\n"},{"id":"200883","messageId":"7vpq4qdbas.fsf@alter.siamese.dyndns.org","threadId":"31764","inReplyTo":"CAB9Jk9AFnauxX0dk8LfpBkpGDSWpWhqnzVew1Eo51K+qEA680A@mail.gmail.com","subject":"Re: git checkout error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-10T07:40:59Z","receivedAt":"2012-10-10T07:40:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Angelo Borsotti <angelo.borsotti@gmail.com> writes:\n\n> Why it is so difficult to convince people to make documentation better?\n\nIt is not difficult.  The discussion on this list is usually done\nvia patches, and without one, constant talking is buried in other\nnoise and often go unnoticed.\n\nThere is however an issue about documentation consistency.  Do we\nuse elsewhere ( A | B | C ... ) to denote \"You must write one (and\nonly one) among A, B, C, ...\" consistently in the documentation?\n\nAn ancient discussion $gmane/72243 might be of interest to kickstart\nsuch a documentation clean-up effort.\n"},{"id":"200892","messageId":"CAB9Jk9BmwuGXsQmQR3Ck58h2uA4gam8n-VWJTwgv_puJZB2sXg@mail.gmail.com","threadId":"31764","inReplyTo":"7vpq4qdbas.fsf@alter.siamese.dyndns.org","subject":"Re: git checkout error","fromName":"Angelo Borsotti","fromEmail":"angelo.borsotti@gmail.com","sentAt":"2012-10-10T08:52:11Z","receivedAt":"2012-10-10T08:52:11Z","isPatch":false,"sender":{"key":"angelo.borsotti@gmail.com","avatar":null},"body":"Hi Junio\n\n> It is not difficult.  The discussion on this list is usually done\n> via patches, and without one, constant talking is buried in other\n> noise and often go unnoticed.\n\nCould you accept for very small changes also the simple indication of\nthe change itself instead of a patch?\n\n>\n> There is however an issue about documentation consistency.  Do we\n> use elsewhere ( A | B | C ... ) to denote \"You must write one (and\n> only one) among A, B, C, ...\" consistently in the documentation?\n\nThere is no standard for it. Posix provides a standard for commands:\n\n     http://pubs.opengroup.org/onlinepubs/9699919799/\n\nbut does not mention (normal) parentheses to indicate choice.\nThere is one applicable standard for this, though, the ISO 14977:\n\n     http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf\n\nwhich gives parentheses \"()\" the meaning of grouping (and then with \"|\"\ninside them, the meaning of choice).\nParentheses are used in:\n\n    - git branch\n    - git commit\n    - git reset\n    - git remote\n    - git submodule\n    - git bisect\n    - git grep\n    - git am\n    - git apply\n    - git format-patch\n    - git cat-file\n    - git commit-tree\n    - git rev-list\n    - git update-index\n\nI did not find in the documentation an explanation of the use of\nparentheses, but\nto me they seem to have been used consistently.\n\n-Angelo\n"}]}