* feature request - have git honor nested .gitconfig files @ 2013-03-22 16:50 Josh Sharpe 2013-03-22 18:22 ` Jonathan Nieder 0 siblings, 1 reply; 8+ messages in thread From: Josh Sharpe @ 2013-03-22 16:50 UTC (permalink / raw) To: git It'd be cool if I were able to override config settings at every nested directory. For example, I have my ~/.gitconfig that has one email address in it, but I also have multiple repos inside ~/dev which I want to use a different email address for. The only way to do that now is to edit all of these: ~/dev/*/.git/conf -- and there are lots of them, and new repos get added all the time - and I forget. If I could add ~/dev/.gitconfig and have the settings in that override ~/.gitconfig then this would be way more manageable. Obviously, individual repo's .git/config should take ultimate precedence. Thanks for the consideration! ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-22 16:50 feature request - have git honor nested .gitconfig files Josh Sharpe @ 2013-03-22 18:22 ` Jonathan Nieder 2013-03-22 18:33 ` Jeff King 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Nieder @ 2013-03-22 18:22 UTC (permalink / raw) To: Josh Sharpe; +Cc: git, Jeff King Hi Josh, Josh Sharpe wrote: > For example, I have my ~/.gitconfig that has one email address in it, > but I also have multiple repos inside ~/dev which I want to use a > different email address for. The only way to do that now is to edit > all of these: ~/dev/*/.git/conf -- and there are lots of them, and new > repos get added all the time - and I forget. A couple of ideas using existing git features: - A wrapper script around "git init" can take care of setting up the shared configuration appropriately based on the repository path. - The extra configuration can be applied on a per-cwd instead of a per-repository basis. Some shells provide a PROMPT_COMMAND facility that can be used to run a command (for example set up environment) each time the prompt is displayed. A PROMPT_COMMAND could set the environment variable EMAIL or GIT_EMAIL based on the value of $PWD. Room for improvement: * A new repository can be created by "git init" or "git clone" and the path where the repository will live is not immediately obvious from the command line, so setting up thorough wrappers is not actually that easy. So this sounds like a good place to provide a hook. (It could be called new-repository or something.) * Maintaining configuration per repository to record a rather simple is more complicated than ideal. It would be easier to understand the configuration if ~/.gitconfig could spell out the rule explicitly: [include] path = cond(starts_with($GIT_DIR, ~/dev/), ~/.config/git/dev-config, ~/.config/git/nondev-config) This means supporting an extension language in the config file. It sounds hard to do right, especially considering use cases like "User runs into trouble, asks a privileged sysadmin to try running a command in her untrusted repository", but it is worth thinking about how to do. * The "Includes" facility is annoyingly close to being helpful. An include.path setting from ~/.gitconfig cannot refer to $GIT_DIR by name. Hope that helps, Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-22 18:22 ` Jonathan Nieder @ 2013-03-22 18:33 ` Jeff King 2013-03-23 0:06 ` Jonathan Nieder 2013-03-23 6:15 ` Thomas Rast 0 siblings, 2 replies; 8+ messages in thread From: Jeff King @ 2013-03-22 18:33 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Josh Sharpe, git On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote: > * Maintaining configuration per repository to record a rather simple > is more complicated than ideal. It would be easier to understand > the configuration if ~/.gitconfig could spell out the rule > explicitly: > > [include] > path = cond(starts_with($GIT_DIR, ~/dev/), > ~/.config/git/dev-config, > ~/.config/git/nondev-config) > > This means supporting an extension language in the config file. > It sounds hard to do right, especially considering use cases like > "User runs into trouble, asks a privileged sysadmin to try running > a command in her untrusted repository", but it is worth thinking > about how to do. I'd rather not invent a new language. It will either not be featureful enough, or will end up bloated. Or both. How about something like: [include] exec = " case \"$GIT_DIR\" in) */dev/*) cat ~/.config/git/dev-config ;; *) cat ~/.config/git/nondev-config ;; esac " It involves a shell invocation, but it's not like we parse config in a tight loop. Bonus points if git provides the name of the current config file, so exec can use relative paths like: cat "$(dirname $GIT_CONFIG_FILE)"/dev-config > * The "Includes" facility is annoyingly close to being helpful. > An include.path setting from ~/.gitconfig cannot refer to $GIT_DIR > by name. Yeah, we do not allow variable expansion at all beyond the usual path mechanisms. I think if you had $GIT_DIR, though, it would end up annoying. You do not want one file in ~/.config/git per $GIT_DIR, so you would need some way of munging $GIT_DIR into your naming scheme. -Peff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-22 18:33 ` Jeff King @ 2013-03-23 0:06 ` Jonathan Nieder 2013-03-23 8:03 ` Jeff King 2013-03-23 6:15 ` Thomas Rast 1 sibling, 1 reply; 8+ messages in thread From: Jonathan Nieder @ 2013-03-23 0:06 UTC (permalink / raw) To: Jeff King; +Cc: Josh Sharpe, git Jeff King wrote: > On Fri, Mar 22, 2013 at 11:22:11AM -0700, Jonathan Nieder wrote: >> It would be easier to understand >> the configuration if ~/.gitconfig could spell out the rule >> explicitly: [...] >> It sounds hard to do right, especially considering use cases like >> "User runs into trouble, asks a privileged sysadmin to try running >> a command in her untrusted repository", but it is worth thinking >> about how to do. > > I'd rather not invent a new language. It will either not be featureful > enough, or will end up bloated. Or both. How about something like: > > [include] > exec = " > case \"$GIT_DIR\" in) > */dev/*) cat ~/.config/git/dev-config ;; > *) cat ~/.config/git/nondev-config ;; > esac > " Yes, an existing language like shell or lua would presumably be the way to go. The scary aspect of shell is the "Prankster sets up a malicious configuration, asks a sysadmin to help in her repository" scenario. Of course we already have that problem with command aliases, but if the sysadmin has perfect spelling then aliases would never trip, so... Hopefully that's enough information for anyone interested to start and understand the relevant variables at play. Thanks, Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-23 0:06 ` Jonathan Nieder @ 2013-03-23 8:03 ` Jeff King 2013-03-24 7:14 ` Junio C Hamano 0 siblings, 1 reply; 8+ messages in thread From: Jeff King @ 2013-03-23 8:03 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Josh Sharpe, git On Fri, Mar 22, 2013 at 05:06:28PM -0700, Jonathan Nieder wrote: > > I'd rather not invent a new language. It will either not be featureful > > enough, or will end up bloated. Or both. How about something like: > > > > [include] > > exec = " > > case \"$GIT_DIR\" in) > > */dev/*) cat ~/.config/git/dev-config ;; > > *) cat ~/.config/git/nondev-config ;; > > esac > > " > > Yes, an existing language like shell or lua would presumably be the > way to go. The scary aspect of shell is the "Prankster sets up a > malicious configuration, asks a sysadmin to help in her repository" > scenario. Of course we already have that problem with command > aliases, but if the sysadmin has perfect spelling then aliases would > never trip, so... And also external diff, textconv, clean/smudge filters, and I'm probably forgetting more. Oh, and hooks. There's definitely a danger to running arbitrary git commands against a maliciously constructed repo. We've tried to make upload-pack safe, so you can at least make your own safe copy to examine. We could probably do more safety checks when the running user and repo owner or not the same, but it would be quite complicated, and in practice it does not seem to be that huge a problem. > Hopefully that's enough information for anyone interested to start and > understand the relevant variables at play. Yeah, I'm not planning to work on this, but I'd be happy to review patches if somebody else wants to. -Peff ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-23 8:03 ` Jeff King @ 2013-03-24 7:14 ` Junio C Hamano 0 siblings, 0 replies; 8+ messages in thread From: Junio C Hamano @ 2013-03-24 7:14 UTC (permalink / raw) To: Jeff King; +Cc: Jonathan Nieder, Josh Sharpe, git Jeff King <peff@peff.net> writes: > Yeah, I'm not planning to work on this, but I'd be happy to review > patches if somebody else wants to. I am not planning to work on this, and honestly speaking I would not be very happy to see any patch in this area. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-22 18:33 ` Jeff King 2013-03-23 0:06 ` Jonathan Nieder @ 2013-03-23 6:15 ` Thomas Rast 2013-03-23 8:06 ` Jeff King 1 sibling, 1 reply; 8+ messages in thread From: Thomas Rast @ 2013-03-23 6:15 UTC (permalink / raw) To: Jeff King; +Cc: Jonathan Nieder, Josh Sharpe, git Jeff King <peff@peff.net> writes: > I'd rather not invent a new language. It will either not be featureful > enough, or will end up bloated. Or both. How about something like: > > [include] > exec = " > case \"$GIT_DIR\" in) > */dev/*) cat ~/.config/git/dev-config ;; > *) cat ~/.config/git/nondev-config ;; > esac > " > > It involves a shell invocation, but it's not like we parse config in a > tight loop. Bonus points if git provides the name of the current config > file, so exec can use relative paths like: We do, however, parse config more than once: $ strace git log -1 2>&1 | grep 'open.*config' open("/home/thomas/.gitconfig", O_RDONLY) = 3 open(".git/config", O_RDONLY) = 3 open("/home/thomas/.gitconfig", O_RDONLY) = 3 open(".git/config", O_RDONLY) = 3 open("/home/thomas/.gitconfig", O_RDONLY) = 3 open(".git/config", O_RDONLY) = 3 open("/home/thomas/.gitconfig", O_RDONLY) = 3 open(".git/config", O_RDONLY) = 3 git-log might be somewhat of an extreme example, but I suspect it's at least twice for all commands (once for repo detection and once for actual parsing). So I further suspect that the slowdown in git's own shellscripts (rebase) would be quite large if you actually spawned two extra shells every time someone says 'git rev-parse ...'. -- Thomas Rast trast@{inf,student}.ethz.ch ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: feature request - have git honor nested .gitconfig files 2013-03-23 6:15 ` Thomas Rast @ 2013-03-23 8:06 ` Jeff King 0 siblings, 0 replies; 8+ messages in thread From: Jeff King @ 2013-03-23 8:06 UTC (permalink / raw) To: Thomas Rast; +Cc: Jonathan Nieder, Josh Sharpe, git On Sat, Mar 23, 2013 at 07:15:42AM +0100, Thomas Rast wrote: > > It involves a shell invocation, but it's not like we parse config in a > > tight loop. Bonus points if git provides the name of the current config > > file, so exec can use relative paths like: > > We do, however, parse config more than once: > > $ strace git log -1 2>&1 | grep 'open.*config' > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > > git-log might be somewhat of an extreme example, but I suspect it's at > least twice for all commands (once for repo detection and once for > actual parsing). So I further suspect that the slowdown in git's own > shellscripts (rebase) would be quite large if you actually spawned two > extra shells every time someone says 'git rev-parse ...'. Yeah, I knew we parsed multiple times in some cases, but I don't think it's that big a deal for a single command. But yeah, it might be noticeable for a shell script which runs lots of git commands. Still, it would only affect people who used the feature. And there is no reason the config system could not learn to cache the results across a single invocation, which would at least drop it to one shell per git command. -Peff ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-03-24 7:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-22 16:50 feature request - have git honor nested .gitconfig files Josh Sharpe 2013-03-22 18:22 ` Jonathan Nieder 2013-03-22 18:33 ` Jeff King 2013-03-23 0:06 ` Jonathan Nieder 2013-03-23 8:03 ` Jeff King 2013-03-24 7:14 ` Junio C Hamano 2013-03-23 6:15 ` Thomas Rast 2013-03-23 8:06 ` Jeff King
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).