Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: [RFC] Update on builtin-commit

From: Kristian Høgsberg <hidden>
Date: 2016-06-15 22:43:19

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:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help