* Re: How should git-config include.path option work in ~/.gitconfig file?
[not found] <CAK6hiNhumFhKd9tjr07SgtZe23LwW8RKSp3BbwVRh06-L0C8EA@mail.gmail.com>
@ 2014-06-21 10:08 ` Jeff King
[not found] ` <CAK6hiNjxeQ6sy1Uk_ApTgKT41cPE-NB1D+ec2JqFvog_9HeFZw@mail.gmail.com>
2014-06-23 17:36 ` Junio C Hamano
0 siblings, 2 replies; 3+ messages in thread
From: Jeff King @ 2014-06-21 10:08 UTC (permalink / raw)
To: Cox, Michael; +Cc: git
[+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
^ permalink raw reply [flat|nested] 3+ messages in thread