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

[Josh Triplett <josh@joshtriplett.org>]

On Thu, Jun 02, 2011 at 07:51:22PM -0700, Junio C Hamano wrote:
> 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.

I do understand your concern, and in the future some tools might need to
support multiple namespaces, but for now all the users only need to use
GIT_NAMESPACE, and I'd prefer to tailor the API for the convenience of
the callers that exist now on the assumption that the API seems trivial
to change later if it turns out we need it.  I don't think it makes
sense to try to design that future API without specific callers in mind.

- Josh Triplett