Possible bug in referenced configuration file loading

Possible bug in referenced configuration file loading

[Raphael Stolt]

Configuration for global ignore patterns in ~/.config/git/config:

[core]
    excludesfile = .gitignore

doesn't get looked up per default in ~/.config/git/ which might be
considered a bug as the .gitignore file isn't loaded. It's only loaded
when .gitignore is located in $HOME or explicitly referenced via
~/.config/git/.gitignore.

Configuration for a conditional include also in ~/.config/git/config:

[includeIf "gitdir:~/Work/git-repos/"]
    path = .oss-gitconfig

does get looked up per default in ~/.config/git/ and  therefor the
.oss-gitconfig is loaded.

So there seems to be a difference in Git's configuration loading strategies.

Environment details:

macOS High Sierra
git version 2.19.1

Windows 10
git version 2.16.1.windows.2

Re: Possible bug in referenced configuration file loading

[Jeff King]

On Fri, Oct 26, 2018 at 09:30:51AM +0200, Raphael Stolt wrote:

> Configuration for global ignore patterns in ~/.config/git/config:
> 
> [core]
>     excludesfile = .gitignore
> 
> doesn't get looked up per default in ~/.config/git/ which might be
> considered a bug as the .gitignore file isn't loaded. It's only loaded
> when .gitignore is located in $HOME or explicitly referenced via
> ~/.config/git/.gitignore.

I don't think we ever defined or documented any behavior for relative
paths in core.excludesFile (nor most other path-based config options).

I suspect it also changes depending on the command, as well as whether
it is a bare or non-bare repository. Because I think it is probably just
wherever the cwd happens to be at the time we parse the config, which is
usually at the top of the working tree (non-bare) or inside the
repository (bare).

> Configuration for a conditional include also in ~/.config/git/config:
> 
> [includeIf "gitdir:~/Work/git-repos/"]
>     path = .oss-gitconfig
> 
> does get looked up per default in ~/.config/git/ and  therefor the
> .oss-gitconfig is loaded.

Whereas config includes have always explicitly advertised from day one
the behavior of relative paths (that they match the surrounding config
file).

I am not opposed to coming up with a rule for relative paths in
excludesFile and other config options. The "pretend as if it is next to
the enclosed config file" rule is sensible to me, but that is not
surprising since I was the one who implemented it for includes. ;)

We'd potentially break some people's config, but I suspect such config
is flaky already (see above).

It would be nice if this were implemented via git_config_pathname() for
consistency, but beware that some options already do specify a behavior
for relative paths, and we would have to make sure not to break that
(e.g., see the documentation and implementation for core.hooksPath).

-Peff