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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jul 17, 2008, 21:45 UTC
Message-ID: <20080717214520.GB2798@spearce.org>
In-Reply-To: <200807172331.18059.robin.rosenberg.lists@dewire.com>

Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

Show 10 quoted lines

> 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.