Re: [RFC] CLI option parsing and usage generation for porcelains
On Sun, Oct 14, 2007 at 09:18:55AM +0000, Eric Wong wrote:
Show 42 quoted lines
> Pierre Habouzit <madcoder@debian.org> wrote:
> > Following Kristian momentum, I've reworked his parse_option module
> > quite a lot, and now have some quite interesting features. The series is
> > available from git://git.madism.org/git.git (branch ph/strbuf).
> >
> > The following series is open for comments, it's not 100% ready for
> > inclusion IMHO, as some details may need to be sorted out first, and
> > that I've not re-read the patches thoroughly yet. Though I uses the tip
> > of that branch as my everyday git for 2 weeks or so without any
> > noticeable issues.
> >
> > And as examples are always easier to grok:
> >
> > $ git fetch -h
> > usage: git-fetch [options] [<repository> <refspec>...]
> >
> > -q, --quiet be quiet
> > -v, --verbose be verbose
> >
> > -a, --append append in .git/FETCH_HEAD
> > -f, --force force non fast-forwards updates
> > --no-tags don't follow tags at all
> > -t, --tags fetch all tags
> > --depth <depth> deepen history of a shallow clone
> >
> > Advanced Options
> > -k, --keep keep downloaded pack
> > -u, --update-head-ok allow to update the head in the current branch
> > --upload-pack <path> path to git-upload-pack on the remote
> >
> > $ git rm -rf xdiff # yeah -rf now works !
>
> Very nice. I worked on gitopt around summer of 2006 but never had the
> time to test it thoroughly. It was a _lot_ more intrusive than yours
> currently is (it touched the diff + revision family of commands).
>
> One feature I really like is automatically handling of long option
> abbreviations. gitopt supported this at the expense of complexity
> and the aforementioned intrusivenes. This allows automatic handling
> of the abbreviation style seen commonly in git shell scripts:
>
> --a|--am|--ame|--amen|--amend) (from git-commit.sh)
Yes, but if you do that, you can't order options in the order you
want (because of first match issues), making the help dumps hopelessly
random. I prefer exact match, especially since your shell can help you
autocomplete the proper command.
I intend to have some magic in the parse_options module to dump the
options in a machine parseable way, so that zsh/bash completion for the
parseopt aware commands is almost trivial. (this was requested from one
of the zsh upstream developpers, and it definitely make sense).
Note that I didn't migrated all the commands yet especially not
diff.c, We'll need a new construct for that: embedding a struct options
array into another to inherit its flags, though I'm not sure it's
enough, as a struct options right now embeds pointers to the variables
it fills, which doesn't work with the "pure" `diff_opt_parse` approach
right now. But I'm sure I'll come up with something :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Pierre Habouzit <madcoder@debian.org>