[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH 1/2] user-manual: add global config section
From:       Felipe Contreras <felipe.contreras () gmail ! com>
Date:       2009-10-14 14:26:39
Message-ID: 94a0d4530910140726i4465e919h77045904aa33c61a () mail ! gmail ! com
[Download RAW message or body]

On Tue, Oct 13, 2009 at 10:19 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 19:09:
>> On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Well, you do talk about "system" below, and that's about it. Also, the
>>> configuration is not really distributed among different locations. Most
>>> newbies interested in a *D*VCS will misunderstand this (as git having
>>> distributed configuration).
>>>
>>> Alternative:
>>>
>>> Git's default configuration can be changed on a system wide, global (per
>>> user) and local (per repository) level, in the order of increasing
>>> precedence.
>>
>> When I read that it's not clear if the local level discards the global
>> level completely or it's aggregated. If we specify that it's only the
>> variables that take precedence it might be clearer:
>>
>> Git's configuration is composed of variables that are stored in
>> multiple locations: 'system' (all users), 'global' (for the user), and
>> 'repository' -- in decreasing order of precedence.
>
> Yep, although established lingo is "options" (not "variables"), and it's
> really increasing order, not decreasing.

Really? I remember clearly Junio stating otherwise:
http://marc.info/?l=git&m=123460371724873&w=2

----
> +	OPT_BOOLEAN(0, "unset", &do_unset, "removes an option: name [value-regex]"),

Please don't introduce a new noun "option" that has never been used to
mean a "configuration variable" in git documentation.  It unnecessarily
confuses everybody.
----

>> I disagree. Most useful configurations (color.ui, user.email) should
>> be global. The complete newbie might think: cool, now I have my git
>> properly configured (with 'git config -e'), and then when cloning a
>> new repo (s)he would think: ok, git just forgot what I told him. When
>> that happens (s)he would have to re-learn and re-configure git.
>>
>> When users think about configuration, it's usually a 'global'
>> configuration, so that's what we should teach from the beginning and
>> make sure they understand the difference between 'global' and
>> 'repository' configurations.
>
> Sure. What I meant are the file locations, the actual paths. First
> timers should use "git config -e" and "git config --global -e" if they
> really want to edit their local and global config files. Better yet,
> they should use "git config" and "git config --global" in their set and
> get modes, because they make sure that there's no total garbage in the
> config. The locations of the files are an implementation detail.

Oh, in that case I agree.

>> Looks better, except s/configuration options/configuration variables/
>>
>
> Uhm, no, for the reason mentioned above. While the man page of git
> config is not completely consistent either, we're really talking about
> configuration options. An "option" can be set to a "value", and the
> thing you pass in order to do that can be called a "variable". For the
> most part this is how git-config[1] uses this terminology.

Yeah, but not everything in there is an option. Personally I would
prefer the "option" term, but as I said, Junio disagreed some time
ago.

-- 
Felipe Contreras
--
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
[prev in list] [next in list] [prev in thread] [next in thread]