Rasmus Villemoes writes:
> Junio C Hamano wrote:
>
>> (by the way, we do not do dashes in names for configuration by
>> convention)
>
> OK. Actually, I now think I'd prefer a subsection [include "safe"], but
> I don't have any strong preferences regarding the names.
I think Peff mentioned somet
Junio C Hamano wrote:
> (by the way, we do not do dashes in names for configuration by
> convention)
OK. Actually, I now think I'd prefer a subsection [include "safe"], but
I don't have any strong preferences regarding the names.
> That syntax _could_ be just a relative path (e.g. project.gitco
Junio C Hamano writes:
> Even though I did allude to ../project.gitconfig in the original message, I
> think there should probably be an explicit syntax to name a path that is
> relative to the root level of the working tree. People do funky things using
> $GIT_DIR and $GIT_WORK_TREE to break the
On Thu, Oct 2, 2014 at 10:27 PM, Junio C Hamano wrote:
> On Thu, Oct 2, 2014 at 6:37 PM, Rasmus Villemoes
> wrote:
>> This adds a variant of the include directive, where only certain
>> config variables in the included files are honoured. The set of
>> honoured variables consists of those the us
On Thu, Oct 2, 2014 at 6:37 PM, Rasmus Villemoes
wrote:
> This adds a variant of the include directive, where only certain
> config variables in the included files are honoured. The set of
> honoured variables consists of those the user has mentioned in a
> safe-include.whitelist directive, along
This adds a variant of the include directive, where only certain
config variables in the included files are honoured. The set of
honoured variables consists of those the user has mentioned in a
safe-include.whitelist directive, along with a small set of git.git
blessed ones.
This can, for example,
6 matches
Mail list logo
