Re: git checkout error
Angelo Borsotti writes: > If they are specified after -b, the command seems to behave as if -b > was not specified, e.g.: > > $ git checkout -b --no-track topic remotes/origin/master -b requires an argument , which you specify as --no-track here. is topic, and the rest is interpreted as . > fatal: git checkout: updating paths is incompatible with switching branches. This error is detected before validating . > while if they are specified before -b the command behaves properly, e.g. > > $ git checkout --no-track -b topic remotes/origin/master > Switched to a new branch 'topic' You can also specify --no-track after -b (and its argument): $ git checkout -b topic --no-track remotes/origin/master Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Andreas Schwab writes: > Angelo Borsotti writes: > >> If they are specified after -b, the command seems to behave as if -b >> was not specified, e.g.: >> >> $ git checkout -b --no-track topic remotes/origin/master > > -b requires an argument , which you specify as --no-track > here. is topic, and the rest is interpreted as . > >> fatal: git checkout: updating paths is incompatible with switching branches. > > This error is detected before validating . > >> while if they are specified before -b the command behaves properly, e.g. >> >> $ git checkout --no-track -b topic remotes/origin/master >> Switched to a new branch 'topic' > > You can also specify --no-track after -b (and its argument): > > $ git checkout -b topic --no-track remotes/origin/master Isn't this "asked and answered" recently with this thread? http://thread.gmane.org/gmane.comp.version-control.git/204397 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Hi Andreas, > > -b requires an argument , which you specify as --no-track > here. is topic, and the rest is interpreted as . > The man page describes --track and --no-track as "options". This is why a reader thinks that they can be specified in any order. It is also very counter-intuitive to think that --no-track is and is topic. This is certainly not what the command does with these data because it creates a new branch whose name is and not --no-track. I proposed a small change that clarifies the syntax, but if you prefer to keep it obscure ... -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Angelo Borsotti writes: > The man page describes --track and --no-track as "options". But the problem you observed is *not* about --track or --no-track. It is about the "-b " option. You used the -b option that requires an argument, and as that argument, you gave a string "--no-track", as if you wanted to create a branch whose name is "--no-track". After these words on the command line are understood, there are two other arguments left on the command line, which is an syntax error as far as "git checkout" is concerned. Again, this is asked-and-answered recently, and http://thread.gmane.org/gmane.comp.version-control.git/204397 has resulted in a leading to b6312c2 (checkout: reorder option handling, 2012-08-30), which is in v1.8.0-rc0 and onwards. You should get an error message that is a lot less confusing: $ git checkout -b --no-track topic remotes/origin/master fatal: '--no-track' is not a valid branch name. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Junio, giving the user a better error message is certainly an improvement. But would not be another improvement to describe better the command syntax so as to help the user write the command right in the first place? After all, what is the syntax section in commands for? If I had seen in the syntax: git checkout [-q] [-f] [-m] [ [--track|--no-track](-b|-B) ] [] I would have written the command correctly, and not even stumbled on a misleading error message. Note that the above syntax is exactly what the command must look like. The syntax is mostly a description of the form of command for the user. Internally, the implementer can use it or can even use a different one (e.g. a more lenient one and detect errors at the semantic level instead). But here what matters is not how the command is implemented, but how the user has to form it. Why it is so difficult to convince people to make documentation better? -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Angelo Borsotti writes: > Why it is so difficult to convince people to make documentation better? It is not difficult. The discussion on this list is usually done via patches, and without one, constant talking is buried in other noise and often go unnoticed. There is however an issue about documentation consistency. Do we use elsewhere ( A | B | C ... ) to denote "You must write one (and only one) among A, B, C, ..." consistently in the documentation? An ancient discussion $gmane/72243 might be of interest to kickstart such a documentation clean-up effort. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout error
Hi Junio > It is not difficult. The discussion on this list is usually done > via patches, and without one, constant talking is buried in other > noise and often go unnoticed. Could you accept for very small changes also the simple indication of the change itself instead of a patch? > > There is however an issue about documentation consistency. Do we > use elsewhere ( A | B | C ... ) to denote "You must write one (and > only one) among A, B, C, ..." consistently in the documentation? There is no standard for it. Posix provides a standard for commands: http://pubs.opengroup.org/onlinepubs/9699919799/ but does not mention (normal) parentheses to indicate choice. There is one applicable standard for this, though, the ISO 14977: http://www.cl.cam.ac.uk/~mgk25/iso-14977.pdf which gives parentheses "()" the meaning of grouping (and then with "|" inside them, the meaning of choice). Parentheses are used in: - git branch - git commit - git reset - git remote - git submodule - git bisect - git grep - git am - git apply - git format-patch - git cat-file - git commit-tree - git rev-list - git update-index I did not find in the documentation an explanation of the use of parentheses, but to me they seem to have been used consistently. -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
