Subject: Re: [JGIT PATCH 1/1] jgit: create a tag command

From: "Shawn O. Pearce" <[email-masked]>
Date: Thu, 17 Jul 2008 21:45:20 +0000

Robin Rosenberg <[email-masked]> wrote:
> lördagen den 12 juli 2008 05.42.06 skrev Shawn O. Pearce:
> > Probably the state-of-the-arg is args4j:
> > 
> >   https://args4j.dev.java.net/
> > 
> > It uses Java 5 annotations to setup the argument parsing:
> 
> But it doesn't use GNU getOpt's long/short style parsing which is a BIG loss. Maybe
> we could contribute it? Or at least not design options incompatible with such an option
> parser.

I'm already using long style options, "--git-dir", "$path" works,
and I taught a subclass wrapper to split "--git-dir=$path" into
the two argument format so we can handle the GNU style long options.

Short style options are harder.  You can alias "-h" to "--help"
and have both respond, but you cannot get option clusters like
"-ar" to expand to "-a","-r" and then parse.  I could have the same
wrapper handle splitting "-ar" into "-a","-r" but it cannot handle
"-C80r" as "-C80","-r" as it doesn't have any information about
what options take values, and which don't.

Getting "--" to terminate the end of options is supported, but
making it handle `git log ref -- path` was interesting.  I had to
make "--" actually an option name, and have it eat all values after
"--" as path specs to implement git-log style arguments.

Looking at the code further its fairly simple.  I don't think it
would be difficult for us to tweak what we need, and try to push
patches upstream.  Well worthwhile actually.  The parser made our pgm
package shorter, and we didn't have to waste time writing our own.
Its well built, and was (mostly) easily extended to handle fully
transparent String->RevCommit or String->RevTree parsing.  So its
worth the few minutes to improve it further.

-- 
Shawn.