On Wed, Jan 30, 2013 at 10:45:37AM -0800, Junio C Hamano wrote: > Teach upload-pack and receive-pack to omit some refs from their > initial advertisements by paying attention to the transfer.hiderefs > multi-valued configuration variable. Any ref that is under the > hierarchies listed on the value of this variable is excluded from > responses to requests made by "ls-remote", "fetch", "clone", "push", > etc. > > A typical use case may be > > [transfer] > hiderefs = refs/pull > > to hide the refs that are internally used by the hosting site and > should not be exposed over the network.
In the earlier review, I mentioned making this per-service, but I see that is not the case here. Do you have an argument against doing so? I'm specifically thinking of the way we do refs/pull at GitHub (which we hide only from receive-pack). I know that you think it would be cleaner to hide those, and at some level I agree. But at the same time, the current mechanism has been in place for some time; changing what we present via upload-pack is likely to break people's workflows. And I have not seen complaints about the current system. So unless there is a compelling reason to do so, I'd rather let the fetcher make the decision. Gerrit's refs/changes may be a different story, if they have a large enough number of them to make upload-pack's ref advertisement overwhelming. I'm happy to do the per-service patch on top, but I just expected it here, so I'm wondering if you are against having the feature. -Peff -- 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
