[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace
From:       Lukas Fleischer <lfleischer () lfos ! de>
Date:       2015-10-31 9:03:11
Message-ID: 20151031090311.26712.64475 () typhoon ! lan
[Download RAW message or body]

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

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.

> > 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!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]