On Sun, Oct 14, 2007 at 09:18:55AM +0000, Eric Wong wrote:
quoted text
> 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).
> >=20
> >   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.
> >=20
> >   And as examples are always easier to grok:
> >=20
> > $ git fetch -h
> > usage: git-fetch [options] [<repository> <refspec>...]
> >=20
> >   -q, --quiet           be quiet
> >   -v, --verbose         be verbose
> >=20
> >   -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
> >=20
> > 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
> >=20
> > $ git rm -rf xdiff # yeah -rf now works !
>=20
> 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).
>=20
> 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:
>=20
>    --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 :)

--=20
=C2=B7O=C2=B7  Pierre Habouzit
=C2=B7=C2=B7O                                                madcoder@debia=
n.org
OOO                                                http://www.madism.org