Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace
From: Lukas Fleischer <hidden>
Date: 2016-06-15 23:07:07
On Fri, 30 Oct 2015 at 22:46:19, Jeff King wrote:
On Fri, Oct 30, 2015 at 02:31:28PM -0700, Junio C Hamano wrote:quoted
Lukas Fleischer [off-list ref] writes:quoted
1. There does not seem to be a way to pass configuration parameters to git-shell commands. Right now, the only way to work around this seems to write a wrapper script around git-shell that catches git-receive-pack commands and executes something like git -c receive.hideRefs=[...] receive-pack [...] instead of forwarding those commands to git-shell.This part we have never discussed in the thread, I think. Why do you need to override, instead of having these in the repository's config files? Is it because a repository may host multiple pseudo repositories in the form of "namespaces" but they must share the same config file, and you would want to customize per "namespace"?
Yes. As I said in the original thread, I want to set receive.hideRefs to
hide everything outside the current namespace, i.e. something equivalent
to
git -c receive.hideRefs='refs/' -c receive.hideRefs="!refs/namespaces/$foo" receive-pack /some/path
if receive.hideRefs would work with absolute (unstripped) namespaces.
quoted
For that we may want to enhance the [include] mechanism. Something like [include "namespace=foo"] path = /path/to/foo/specific/config.txt [include "namespace=bar"] path = /path/to/bar/specific/config.txt Cc'ing Peff as we have discussed this kind of conditional inclusion in the past...
That would work but it would still be very cumbersome. Imagine that there is a single repository with 100000 pseudo repositories inside. You really don't want to create a config file and a indirection in the main configuration for each of these pseudo repositories, just to build a configuration equivalent to the single line I described above.
[...] I am slightly confused, though, where the namespace is set in such a git-shell example. I have no really used ref namespaces myself, but my understanding is that they have to come from the environment. You can similarly set config through the environment. I don't think we've ever publicized that, but it is how "git -c" works. E.g.: $ git -c alias.foo='!env' -c another.option=true foo | grep GIT_ GIT_CONFIG_PARAMETERS='alias.foo='\!'env' 'another.option=true' [...]
Yes, the Git namespace is passed through the environment by setting GIT_NAMESPACE and GIT_CONFIG_PARAMETERS is exactly what I was looking for! Thanks!