Re: [RFC] Update on builtin-commit

From: Kristian Høgsberg <krh@redhat.com>
Date: Jul 2, 2007, 17:57 UTC
Message-ID: <1183399050.30611.25.camel@hinata.boston.redhat.com>
In-Reply-To: <1183397689.10996.11.camel@lt21223.campus.dmacc.edu>

On Mon, 2007-07-02 at 12:34 -0500, Jeffrey C. Ollie wrote:

Show 10 quoted lines

> On Mon, 2007-07-02 at 18:02 +0100, Johannes Schindelin wrote:
> >
> > Hmm. Somehow I think that the getopt solution is not so bad at all. We'd 
> > need some code in compat/, but since we're GPL, and there are so many 
> > GPLed getopt versions out there, I don't see any obstacle there.
> 
> If we are going to make this option parser into some complex
> general-purpose option parsing library let's not re-invent the wheel.
> Let's pick one of the GPL'd option parsing libraries and make it a
> dependency of Git.

I don't have much of an opinion here; as I've said before, my goal here is to get commit ported to C, and I specifically don't want to block on the option parser discussion reaching consensus. One thing I do not want to do, though, is to explode the current table driven approach into a gazillion strcmps. Other than that I'm open to porting it to an external getopt dependency, adding the couple of missing features Johannes mentioned (bundling and ordering), or just keeping it local to builtin-commit.c as is.

That said, we're debating less than 100 lines of code. Adding the bundling of short options and some kind of ordering mechanism would add at most 20 more lines. Is it worth taking a getopt dependency for that?

Kristian