Junio C Hamano <gitster@xxxxxxxxx> writes: > Angelo Borsotti <angelo.borsotti@xxxxxxxxx> writes: > >> It makes quite clear that the command accepts wildcards >> (not expanded by the shell), which was is not clear in the current >> man page (although one could imagine that <path> could also be a >> wildcard). >> >> P.S. In the man page there is also a <pathspec> >> >> "*git checkout* [-p|--patch] [<tree-ish>] [--] <pathspec>... >> >> that should perhaps be a <path> > > That's backwards. Saying <path> as if it means a plain vanilla > pathname is a cause of confusion. The command takes pathspec, which > is a pattern (see "git help glossary"). The places in the text that > say <path> may need to be fixed. > > It just happens that you do not realize that you are using pathspec > when you say "git checkout hello.c", as the pattern "hello.c" only > matches the one pathname "hello.c". I've read Documentation/git-checkout.txt and looked at the use of "paths". the most of the "paths" (if not all) in the description are used as short-hand to mean "paths that the end user specified by giving a pathspec without repeating that expression over and over again. And it should be clear from the context, especially in places where we say things like "It updates the named paths", "update the index for the given paths", "checking out paths from the index", "when paths are given" etc. As long as readers notice that the command takes <pathspec> on the command line, and understand <pathspec> has a specific meaning (i.e. it is a way to specify set of paths to be manipulated) and semantics, the existing text should be OK. The <paths> in synopsis section should be updated to <pathspec>, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html