Re: [RFC] Update on builtin-commit

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 2, 2007, 17:02 UTC
Message-ID: <Pine.LNX.4.64.0707021758090.4071@racer.site>
In-Reply-To: <1183395082.30611.16.camel@hinata.boston.redhat.com>

Hi,

On Mon, 2 Jul 2007, Kristian H?gsberg wrote:

Show 11 quoted lines

> On Mon, 2007-07-02 at 17:11 +0100, Johannes Schindelin wrote:
> > just a quick comment on the option parser:
> > 
> > On most platforms, sizeof(void*)>=sizeof(int). But I would not rely on 
> > that. Rather (also because it is prettier), I'd use "union".
> 
> In the OPTION_INTEGER case, the 'value' void pointer points to an 
> integer global that's set to the value passed.  In the OPTION_NONE, it 
> also points to an integer, which is set to 1 if the option is seen.  So 
> I'm relying on sizeof(void*) == sizeof(int*), but I'm not storing ints 
> in pointers.

Ah, right.

Show 5 quoted lines

> > Besides, your option parser loses order information, correct? IOW, 
> > something like "--color --no-color --color" would confuse it.
> 
> Yes, I don't record the order of options, but in the builtin-commit 
> case, I don't think there are any options where that makes a difference?

That might be correct now. But why not make the option parser general enough to (finally!) support something like "git clone -lns <directory>", i.e. short options a la GNU? This is something that has been wanted for a long time.

Besides, if you make the option parser not general enough to be reused in all git programs, I wonder why bother at all? It's not like it is less complex than a hand-rolled option parser, if it is used only once.

Show 6 quoted lines

> In cases where order is important or we have an option that negates the 
> effect of another option (your --no-color example), we could either 1) 
> extend the option struct with a 'disable' name that flips the value back 
> to 0 or 2) instead of just setting it to 1, record the index of the 
> options passed and compare the indexes of conflicting options to see 
> which one was passed last.

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.

Ciao, Dscho