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

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

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"?

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