git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kristian Høgsberg" <krh@redhat.com>
To: "Jeffrey C. Ollie" <jeff@ocjtech.us>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [RFC] Update on builtin-commit
Date: Mon, 02 Jul 2007 13:57:30 -0400	[thread overview]
Message-ID: <1183399050.30611.25.camel@hinata.boston.redhat.com> (raw)
In-Reply-To: <1183397689.10996.11.camel@lt21223.campus.dmacc.edu>

On Mon, 2007-07-02 at 12:34 -0500, Jeffrey C. Ollie wrote:
> 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

      reply	other threads:[~2007-07-02 17:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-02 14:22 [RFC] Update on builtin-commit Kristian Høgsberg
2007-07-02 16:11 ` Johannes Schindelin
2007-07-02 16:51   ` Kristian Høgsberg
2007-07-02 17:02     ` Johannes Schindelin
2007-07-02 17:34       ` Jeffrey C. Ollie
2007-07-02 17:57         ` Kristian Høgsberg [this message]

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=1183399050.30611.25.camel@hinata.boston.redhat.com \
    --to=krh@redhat.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jeff@ocjtech.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).