Re: Possible bug in referenced configuration file loading

From: Jeff King <peff@peff.net>
Date: Oct 26, 2018, 07:58 UTC
Message-ID: <20181026075841.GB3119@sigill.intra.peff.net>
In-Reply-To: <CAM-9DY2KVjq2879TJUNhBsRBbAjScMS7U5scP-fAY0NsvCan9A@mail.gmail.com>

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

Show 9 quoted lines

> 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).

Show 7 quoted lines

> 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