Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

> Josh Triplett <josh@joshtriplett.org> writes:
> 
> > ... I don't think it
> > makes sense to support passing in arbitrary namespaces when the callers
> > only use it to access the currently requested namespace.  If some
> > situation arises in later code that needs to handle arbitrary
> > namespaces, it seems easy enough to provide a more generalized function
> > at that point, but doing so now would just make the existing callers
> > more complex by forcing them to do the call to get_git_namespace()
> > rather than allowing for_each_namespaced_ref to do it.
> 
> If you do not pass the namespace around from day one, wouldn't it make it
> more cumbersome to later extend the API so that you can have more than one
> namespace active at the same time? For example, even with today's code,
> when responding to a push, the receiving repository issues a ls-remote
> request to its alternate repository to learn the tips of its refs, and at
> that point, the side of you who is responding to a push is using the
> namespace from the push client, while you acting as a fetch/ls-remote
> client would be in a different namespace. The different namespace happens
> to be "no funny namespace business" plain vanilla one, but I think you get
> the point. I do not mind seeing the very top-level caller of ref iterator
> calling get-namespace, but I would find it a bad taste if a function very
> deep in a callchain has to call get-namespace (meaning, you can only have
> one namespace active at a time) only because the caller does not pass it
> in.
> 
> But perhaps I am looking too far into the future and worried too much.