Re: [PATCH 12/18] revert: Save command-line options for continuing operation
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- Jul 27, 2011, 15:49 UTC
- Message-ID
- <CALkWK0=y4qzEOgvn+1WfHuMeCmx8=bgbUKSPQiT7Eram9xiHug@mail.gmail.com>
- In-Reply-To
- <20110727142116.GB24785@elie>
Hi again,
Jonathan Nieder writes:
Show 11 quoted lines
> 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.
Show 8 quoted lines
> 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).
Show 5 quoted lines
> 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