Re: Cleaning up git user-interface warts

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