On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano <gits...@pobox.com> 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 > > The changes necessary on the client side to allow fetching objects > at the tip of a ref in hidden hierarchies are much more involved and > not part of this early preview, but the end user UI is expected to > be like these: > > $ git fetch $there refs/changes/72/41672/1 > $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182 > > That is, you ask for a refname as usual even though it is not part > of ls-remote response, or you ask for the commit object that is at > the tip of whatever hidden ref you are interested in.
Should the client side learn how to list hidden refs too? I'm thinking of an extreme case where upload-pack advertises nothing (or maybe just refs/heads/master) and it's up to the client to ask for the ref selection it's interested in. upload-pack may need more updates to do that, I think. -- Duy -- 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
