Hi Michael, Michael Haggerty wrote: > I would again like to express my discomfort about this feature, which is > already listed as "will merge to next". Frankly, I have the feeling > that this feature is being steamrolled in before a community consensus > has been reached and indeed before many valid points raised by other > members of the community have even been addressed. For example: In $dayjob I work with Gerrit, so I think I can start to answer some of these questions. > * I didn't see a response to Peff's convincing arguments that this > should be a client-side feature rather than a server-side feature [1]. The client can't control the size of the ref advertisement. That is the main motivation if I understood correctly. > * I didn't see an answer to Duy's question [2] about what is different > between the proposed feature and gitnamespaces. Namespaces are more complicated and don't sit well in existing setups involving git repositories whose refs are not namespaced. > * I didn't see a response to my worries that this feature could be > abused [3]. Can you elaborate? Do you mean that through social engineering an attacker would convince the server admin to store secrets using a hidden ref and enable the upload-archive service? That does sound like a reasonable concern. Perhaps the documentation should be updated along these lines transfer.hiderefs:: String(s) `upload-pack` and `receive-pack` use to decide which refs to omit from their initial advertisement. Use more than one transfer.hiderefs configuration variables to specify multiple prefix strings. A ref that are under the hierarchies listed on the value of this variable is excluded, and is hidden from `git ls-remote`, `git fetch`, `git push :`, etc. An attempt to update or delete a hidden ref by `git push` is rejected, and an attempt to fetch a hidden ref by `git fetch` will fail. + This setting does not currently affect the `upload-archive` service. until someone interested implements the same for upload-archive. > I also think that the feature is poorly designed. For example: That's another reasonable concern. It's very hard to get a design correct right away, which is presumably part of the motivation of getting this into the hands of interested users who can give feedback on it. What would potentially be worth blocking even that is concerns about the wire protocol, since it is hard to take back mistakes there. > * Why should a repository have exactly one setting for what refs should > be hidden? Wouldn't it make more sense to allow multiple "views" to be > defined?: How do I request a different view of the repository at /path/to/repo.git over the network? How can we make the common case of only one view easy to achieve? Isn't the multiple-views case exactly what gitnamespaces is for? [...] > * Is it enough to support only reference exclusion (as opposed to > exclusion and inclusion rules)? The motivating example is turning off advertisement of the refs/changes hierarchy. If and when more complicated cases come up, that would presumably be the time to support more complicated configuration. [...] > * Why should this feature only be available remotely? It is about transport. Ref namespaces have their own set of use cases and are a distinct feature. Hoping that clarifies, Jonathan -- 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