Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html