Re: How should git-config include.path option work in ~/.gitconfig file?

Re: How should git-config include.path option work in ~/.gitconfig file?

[Jeff King]

[+cc mailing list]

On Sat, Jun 21, 2014 at 03:16:05AM -0600, Cox, Michael wrote:

> I discovered the new (to me, at least) git config include.path option
> recently and tried using it to include a file, .gitremotes in my git
> worktree.  The .gitremotes file contains a remote.upstream section
> containing information (url, fetch, etc.) for the upstream remote I'm using
> to fetch updates for the project I'm working on, e.g.
> 
> [remote "upstream"]
> url = http://github.com/diydrones/ardupilot
> fetch = +refs/heads/*:refs/remotes/upstream/*
> 
> When I add
> 
> [include]
> path = ../.gitremotes
> 
> to my .git/config file, everything works as expected.

So far so good, though note the potential security implications. If the
upstream you fetch from puts something malicious into .gitremotes, they
could execute arbitrary code (e.g., by setting up external diff config).

That may be a tradeoff you're OK with, but I wanted to point it out to
make sure you are aware.

> I then thought I'd like to make this work for all my repositories by
> default by adding the above include.path option to my global ~/.gitconfig
> file. This way I would not have to run "git config include.path
> ../.gitremotes" for each of my repositories and the .gitremotes file would
> server as documentation of the official remote repositories for the
> project. The documentation for the git config include.path option does
> state that relative paths are relative to the including config file. But
> the ~/.gitconfig file is supposed to contain common configuration options
> that appear in all your git repositories.

The including config file in that case would be ~/.gitconfig, and the
included path is relative to it.

Your final sentence seems to me to be the one that introduces the
confusion. Options in .gitconfig do not "appear in all your git
repositories". Rather, when a git command is run, it consults the
repo-local $GIT_DIR/config, the global ~/.gitconfig file, and the
system-level /etc/gitconfig.

> So is this a bug or a feature?

Feature. :)

> It seems like the currently documented behavior of include.path and
> .gitconfig are conflicting. I can see how having include.path
> statements in your .gitconfig file that are processed immediately
> would be useful for modularizing your .gitconfig file, but I think my
> use case is also a valuable use of the include.path functionality.
> Not sure how to syntactically express the deferral of the include file
> processing in the .gitconfig file, though.

Yes, the design of includes from ~/.gitconfig is very intentional, and
not going to change (and even if it weren't, we would have to deal with
backwards compatibility while changing it).  I agree what you are trying
to do is a sane thing (the security implications of pointing straight
into the work-tree aside, you could easily be doing the same thing with
another file in $GIT_DIR, or any number of similar schemes).

There isn't currently a way to do what you want. I think we would need a
new syntax for it. Recently we discussed supporting environment
variables in expansions of path-oriented config variables. So something
like:

  [include]
  path = $GIT_DIR/../.gitremotes

would do what you want. We'd have to give some thought on what that
should do when $GIT_DIR is not set (e.g., when you run a git command
outside of a repository). I'd be inclined to say that such an include
should be ignored (the naive shell interpretation would be to look for
"/../.gitremotes", which is almost certainly not what the user wants).

> P.S.  I searched the archive and found your patch submittal.  I wasn't sure
> if I should post this to git@vger.kernel.org, so I decided it would be
> better to check with the original feature developer first.  Sorry if that
> was a violation of this mailing list's etiquette.

This is definitely the sort of thing that should be discussed on the
mailing list. I've added it to the cc so we can continue the discussion
there.

-Peff

Re: How should git-config include.path option work in ~/.gitconfig file?

[Jeff King]

On Sun, Jun 22, 2014 at 01:00:53PM -0600, Cox, Michael wrote:

> I like the idea of recognizing environment variable syntax in config files,
> at least a feature that would allow *some* config variables to be specified
> as accepting environment variable syntax.  It adds a lot of flexibility,
> but I'm sure it might also introduce security issues that I am completely
> unaware of (like the  issue you made me aware of above).

I don't think there are any security issues; if you control the
environment, you can already execute arbitrary code with git.

Now we just need somebody to volunteer to implement it. :)

-Peff

Re: How should git-config include.path option work in ~/.gitconfig file?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... Recently we discussed supporting environment
> variables in expansions of path-oriented config variables. So something
> like:
>
>   [include]
>   path = $GIT_DIR/../.gitremotes
>
> would do what you want. We'd have to give some thought on what that
> should do when $GIT_DIR is not set (e.g., when you run a git command
> outside of a repository). I'd be inclined to say that such an include
> should be ignored (the naive shell interpretation would be to look for
> "/../.gitremotes", which is almost certainly not what the user wants).

I agree with everything in the above paragraph.
Thanks for forwarding.