Johannes Schindelin wrote:
quoted text
> 
> On Fri, 19 Jan 2007, Jakub Narebski wrote: 

quoted text
>> +in the section header, like in example below
>> +
>> +	[section "subsection"]
> 
> I wonder if we should also mention the (case insensitive) alternative 
> "[section.subsection]", to give a better idea to people why we actually 
> check for "section.subsection" in the code.

I'm not sure. "section.subsection" can be treated as section with that
name, strange because it has '.' in it, and not subsection "subsection"
of section "section". git-repo-config writes section with subsection
in above format.
 
quoted text
>> +All the other lines 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".
>> +Variable names are case insensitive.
> 
> They cannot contain anything else than alphanumeric characters, in 
> particular no whitespace.

Contrary to for example also ini-like smb.conf:
  Leading, trailing and _internal_ whitespace in section and parameter
  names is  irrelevant.

quoted text
>>					 There can be more than one value
>> +for a given variable; we say then that variable is multivalued.
> 
> Maybe give the example of "remote.<name>.fetch" to explain why? Or maybe 
> not.

I put it because in this git config differs from standard ini-format.

quoted text
>> +The following escape sequences (beside `\"` and `\`) are recognized:
>> +`\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB)
>> +and `\b` for backspace (BS).  No other character escape codes, nor octal
>> +char sequences are valid.
> 
> I did not even know about BS! Does it make sense to allow it, really?

That is the question I'm also asking...

quoted text
>> +Some variables may require special value format.
> 
> I think you can safely skip that; it should be evident that the format of 
> the variables depends on the purpose.

This was in the original, and I think it is better left (at least for now).

I wonder if to write about --bool and --int formats...
-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html