All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Habouzit <madcoder@debian.org>
To: "Kristian Høgsberg" <krh@redhat.com>,
	git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] Add a simple option parser.
Date: Thu, 04 Oct 2007 18:31:56 +0200	[thread overview]
Message-ID: <20071004163156.GD5083@artemis.corp> (raw)
In-Reply-To: <20071004151532.GB5083@artemis.corp>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

On jeu, oct 04, 2007 at 03:15:32 +0000, Pierre Habouzit wrote:
> On Thu, Oct 04, 2007 at 02:57:58PM +0000, Kristian Høgsberg wrote:
> > I'm not sure - we can go with the current proposal and add new options
> > types and probably the callback option type I suggested as we go.  I
> > don't want to block builtin-commit on figuring out what the perfect
> > option parser should look like and what I sent out earlier work for
> > commit.  I think the way you handled the strbuf rewrites worked pretty
> > well; extending and rewriting the API as you put it to use in more and
> > more places.  We can do the same thing with parse_options().
> 
>   Of course we can do that, or junio said that some people talked about
> popt some time ago. I understand that you don't want to block the
> git-commit work, but doing things right from the beginning is often a
> big win on the long term.
> 
>   I don't know popt, and I don't know if it has sufficient expressivity.
> For sure I don't like getopt_long APIs at all, so if popt is as
> cumbersome, rolling our own based on the current parse_options you
> propose is probably a good choice.

  Okay, popt seems to be quite complicated, and depends upon gettext
(which we may require as per survey results, but right now it seems a
useless dependency). Don't get me wrong, I'm sure it's very powerful,
but again, I believe we can have a 200 line ad-hoc module that fits what
git really needs, the less cumbersome way.

  So well, I'd be (I'm not in position to decide anything btw ;p) in
favor of pursuing the work into git-commit like you did, and ASAP it
gets merged into next, I'm definitely willing to pursue a refactoring to
use it (now that strbufs seems to have been used where needed).

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-10-04 16:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-03 21:45 [PATCH] Add a simple option parser Kristian Høgsberg
2007-10-03 21:45 ` [PATCH] Port builtin-add.c to use the new " Kristian Høgsberg
2007-10-03 23:11 ` [PATCH] Add a simple " Pierre Habouzit
2007-10-04 14:57   ` Kristian Høgsberg
2007-10-04 15:15     ` Pierre Habouzit
2007-10-04 16:31       ` Pierre Habouzit [this message]
2007-10-04 16:39         ` Johannes Schindelin
2007-10-05 10:08 ` Pierre Habouzit
2007-10-05 14:21 ` Pierre Habouzit
2007-10-05 14:25   ` [ALTERNATE PATCH] " Pierre Habouzit
2007-10-05 14:30     ` Mike Hommey
2007-10-05 14:45       ` Pierre Habouzit
2007-10-05 15:45         ` Medve Emilian-EMMEDVE1
2007-10-05 15:56           ` Pierre Habouzit
2007-10-05 16:10             ` Medve Emilian-EMMEDVE1
2007-10-05 16:20               ` David Kastrup
2007-10-05 16:38                 ` Pierre Habouzit
2007-10-06  8:46                   ` Sven Verdoolaege
2007-10-05 16:28               ` Linus Torvalds
2007-10-05 16:41                 ` Medve Emilian-EMMEDVE1
2007-10-05 16:49                   ` Pierre Habouzit
2007-10-05 16:51                   ` Linus Torvalds
2007-10-05 14:59       ` David Kastrup
2007-10-05 15:33     ` Kristian Høgsberg
2007-10-05 15:54       ` Pierre Habouzit
2007-10-07 17:01     ` Pierre Habouzit
2007-10-13 13:29 [RFC] CLI option parsing and usage generation for porcelains Pierre Habouzit
     [not found] ` <1192282153-26684-2-git-send-email-madcoder@debian.org>
2007-10-13 14:39   ` [PATCH] Add a simple option parser Johannes Schindelin
2007-10-13 14:58     ` Pierre Habouzit
2007-10-13 19:16   ` Alex Riesen
2007-10-13 20:54     ` Pierre Habouzit
2007-10-13 22:14       ` Alex Riesen
2007-10-14  7:02         ` Pierre Habouzit

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=20071004163156.GD5083@artemis.corp \
    --to=madcoder@debian.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=krh@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.