Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace

From: Jeff King <peff@peff.net>
Date: Oct 30, 2015, 21:46 UTC
Message-ID: <20151030214618.GA11426@sigill.intra.peff.net>
In-Reply-To: <xmqqmvv0jb67.fsf@gitster.mtv.corp.google.com>

On Fri, Oct 30, 2015 at 02:31:28PM -0700, Junio C Hamano wrote:

Show 30 quoted lines

> Lukas Fleischer <lfleischer@lfos.de> writes:
> 
> > 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"?
> 
> 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...

Yeah, that sort of conditional matching is exactly what I had intended for the "subsection" of include to be. We just haven't come up with a good condition to act as our first use case. :)

I am happy with any syntax that does not paint us into a corner (and your example above looks fine, assuming we could later add other keys on the left-hand of the "=").

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'

I think it is very particular that you single-quote each item, though:

  $ GIT_CONFIG_PARAMETERS=foo.bar=true git config foo.bar
  error: bogus format in GIT_CONFIG_PARAMETERS
  fatal: unable to parse command-line config

  $ GIT_CONFIG_PARAMETERS="'foo.bar=true'" git config foo.bar
  true

So we may want to make it a little more friendly before truly recommending it as an interface, but I don't think there is any conceptual problem with doing so.

-Peff