From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Wed, 27 Jul 2011 09:51:43 GMT
Subject: Re: [PATCH 12/18] revert: Save command-line options for continuing operation
Message-ID: <CALkWK0=5drVxLe4SAVLem3cpWCB=Eg3dTFQGhLKFD+Z77RHohA@mail.gmail.com>
In-Reply-To: <20110727050515.GH18470@elie>

Hi again,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> In the same spirit as ".git/sequencer/head" and ".git/sequencer/todo",
>> introduce ".git/sequencer/opts" to persist the replay_opts structure
>> for continuing after a conflict resolution.  Use the gitconfig format
>> for this file so that it looks like:
>>
>> [core]
>>       signoff = true
>>       record-origin = true
>>       mainline = 1
>>       strategy = recursive
>>       strategy-option = patience
>>       strategy-option = ours
>
> Maybe "[options]" instead of "[core]" would be more self-explanatory.

Fixed, thanks.

> If this is meant to be closely analagous to the gitconfig file, then
> variable names should not contain dashes.

Huh?  Quoting Documentation/config.txt:

All the other lines (and the remainder of the line after the section
header) are recognized as setting variables, in the form
'name = value'.  If there is no equal sign on the line, the entire line
is taken as 'name' and the variable is recognized as boolean "true".
The variable names are case-insensitive and only alphanumeric
characters and `-` are allowed.  There can be more than one value
for a given variable; we say then that variable is multivalued.

Btw, the multi-value thing is something I wasn't aware about earlier;
that's what led to the " | " ugliness in my earlier patch.

> 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?

-- Ram