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 .
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  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 .
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
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