From: "Shawn O. Pearce" <spearce@spearce•org>
To: Robin Rosenberg <robin.rosenberg.lists@dewire•com>
Cc: Mike Ralphson <mike.ralphson@gmail•com>,
Marek Zawirski <marek.zawirski@gmail•com>,
git@vger•kernel.org
Subject: Re: [JGIT PATCH 1/1] jgit: create a tag command
Date: Thu, 17 Jul 2008 21:45:20 +0000 [thread overview]
Message-ID: <20080717214520.GB2798@spearce.org> (raw)
In-Reply-To: <200807172331.18059.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire•com> 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.
next prev parent reply other threads:[~2008-07-17 21:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-06 22:41 [JGIT PATCH 1/1] jgit: create a tag command Robin Rosenberg
2008-07-06 23:16 ` Robin Rosenberg
2008-07-10 15:31 ` Mike Ralphson
2008-07-10 18:02 ` Robin Rosenberg
2008-07-11 10:50 ` Differences between git-applu and GNU patch (was: [JGIT PATCH 1/1] jgit: create a tag command) Jakub Narebski
2008-07-11 2:05 ` [JGIT PATCH 1/1] jgit: create a tag command Shawn O. Pearce
2008-07-11 8:28 ` Robin Rosenberg
2008-07-11 8:45 ` Mike Ralphson
2008-07-12 3:01 ` Shawn O. Pearce
2008-07-12 3:42 ` Shawn O. Pearce
2008-07-17 21:31 ` Robin Rosenberg
2008-07-17 21:45 ` Shawn O. Pearce [this message]
2008-07-17 22:24 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080717214520.GB2798@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=marek.zawirski@gmail$(echo .)com \
--cc=mike.ralphson@gmail$(echo .)com \
--cc=robin.rosenberg.lists@dewire$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox