On Fri, Jan 18, 2013 at 04:37:04PM -0800, Junio C Hamano wrote: > This is an early preview of reducing the network cost while talking > with a repository with tons of refs, most of which are of use by > very narrow audiences (e.g. refs under Gerrit's refs/changes/ are > useful only for people who are interested in the changes under > review). As long as these narrow audiences have a way to learn the > names of refs or objects pointed at by the refs out-of-band, it is > not necessary to advertise these refs. > > On the server end, you tell upload-pack that some refs do not have > to be advertised with the uploadPack.hiderefs multi-valued > configuration variable: > > [uploadPack] > hiderefs = refs/changes Would you want to do the same thing on receive-pack? It could benefit from the same reduction in network cost (although it tends to be invoked less frequently than upload-pack). At GitHub, we have a similar patch (we even call it hiderefs), but we do it only for receive-pack. In our case, it is not about network traffic, but rather that we provide a set of read-only refs in the refs/pull hierarchy. These are generated upstream by the creation of pull requests, and we reject any updates to them via the git protocol using a pre-receive hook. However, if a client without these refs uses "git push --mirror", it will attempt to delete them (which will fail). Meaning that a mirror push will always report failure, because it will always fail to push the refs/pull deletions. I don't know much about Gerrit's inner workings. Are refs/changes also read-only? -Peff -- 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