Michael Haggerty <mhag...@alum.mit.edu> writes: > I would again like to express my discomfort about this feature, which is > already listed as "will merge to next".
Do not take "will merge to next" too literally. One major purpose of marking a topic as such is exactly to solicit comments like this ;-) > * 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]. Uncluttering is not about a choice client should make. "delayed advertisement" is an orthogonal issue and requires a larger protocol update (it needs to make "git fetch" speak first instead of the current protocol in which "upload-pack" speaks first). > * I didn't see an answer to Duy's question [2] about what is different > between the proposed feature and gitnamespaces. I think Jonathan addressed this already. > * I didn't see a response to my worries that this feature could be > abused [3]. You can choose not to advertise allow-tip-sha1-in-want capability; I do not think it is making things worse than the status quo. > * 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?: You are welcome to extend to have different views, but how would your clients express which view they would want? Giving a single view that the serving end decides gives us an immediate benefit of showing an uncluttered set of refs of server's choice, without making the problem space larger than necessary. > * Is it enough to support only reference exclusion (as opposed to > exclusion and inclusion rules)? Again, I do not think you cannot extend it to do positive and negative filtering "exclude these, but include those even though they match the 'exclude these' patterns I gave you earlier". > * Why should this feature only be available remotely? The whole point is to give the server side a choice to show selected refs, so that it can use hidden portion for its own use. These refs should not be hidden from local operations like "gc". I appreciate the comments, but I do not think any point you raised in this message is very much relevant as objections. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html