From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Wed, 27 Jul 2011 15:49:50 GMT
Subject: Re: [PATCH 12/18] revert: Save command-line options for continuing operation
Message-ID: <CALkWK0=y4qzEOgvn+1WfHuMeCmx8=bgbUKSPQiT7Eram9xiHug@mail.gmail.com>
In-Reply-To: <20110727142116.GB24785@elie>

Hi again,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> Jonathan Nieder writes:
>>> It would be nice if some
>>> day the config parser could learn to treat dashes as insignificant,
>>> just like it already treats case distinctions as insignificant.
>>
>> Is the documentation out of date? I can't find any special handling
>> for `-` in the code either.  What are you talking about?
>
> "It would be nice if some day the config parser could learn" implies
> "The config parser does not behave like this", no?

Ah, I misread that.  Sorry.

> One problem with dashes in names of real configuration variables is
> that most git multi-word configuration variables are already named
> using InsignificantBumpyCaps, which means the user does not have to
> remember where the word breaks are as language drifts (e.g., is it a
> "file name" or a "filename"?).  A convention of using dashes to
> separate words would probably have been about as good, while
> inconsistently sometimes using dashes and sometimes not would be far
> worse.

Hm, case insensitivity is nice, but ignoring dashes may not be such a
good idea.  I suppose we can use them where it's totally sensible and
unambiguous like in this case (command-line options).

> Of course, the .git/sequencer/args file is not gitconfig, and changes
> in its format are not as hard (since unlike for gitconfig, any
> backward-compatibility synonyms probably do not need to be mentioned
> in documentation).  So I am not too worried and this was mostly an
> aside.

Cool.  Thanks.

-- Ram