Han-Wen Nienhuys wrote: > As another example: annoyances regarding program invocation > > - option handling: -x -f -z != -xfz , "--max-count 1" doesn't work, > but needs an '=' That's true, and the probable cause is that git tries to first, avoid dependency on options parsers like getopt/getopt_long/argp or popt for commands in C, getopt for commands in shell, Getopt::Std/Getopt::Long for commands in Perl, and something for commands in Python (if there are any left); second, existing options parsers do not deal (I think) with distinction between arguments to wrapper and arguments to command, '--' to separate revisions from pathnames not options from arguments, and the whole revisions and revision list specifying syntax (where "a --not b" is not equivalent to "--not a b"). That said, perhaps we should craft our own options parsing (or modify existing one)... > - git --help lists an unordered set, which is too long scan quickly. It is one page of alphabetically ordered commands. git(7) gives whole list of commands, divided into categories, by the way. > I'd expect that list to either contain everything or the minimum set for > daily use. I.e. the set introduced in a first tutorial. Why are merge, > prune, verify-tag there? > > Try "bzr help" for comparison. I wonder why "repack" isn't there, if "prune" is. > - --pretty option with wholly uninformative options full, medium, > short, raw. It's not even documented what each option does. And 'oneline' and undocumented 'email'. True, git lacks documentation (and this one of main complaints in git survey). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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