On Fri, Sep 02, 2016 at 07:03:30PM -0700, Shawn Pearce wrote: > > Is it useful for upload-pack? If we have no refs, there's traditionally > > been nothing to fetch. Perhaps that's something that could change, > > though. For example, there could be a capability to allow fetching > > arbitrary sha1s (we have allowTIPSH1InWant and allowReachableSHA1InWant, > > which obviously both require some refs, but allowArbitrarySHA1 does not > > seem outside the realm of possibility). > > Its exactly these sort of extra capabilities. We run JGit in modes > where "out of band" (e.g. URL or higher level protocol framing like an > undocumented HTTP header) allows the fetch-pack client to say "do not > send me advertisements, but I want to learn your capabilities". The > fetch-pack client typically activates the allow-reachable-sha1-in-want > feature and names specific SHA-1s it wants. So it sounds like you _could_ enable this only in out-of-band mode, without loss of functionality. I don't particularly care either way (I do not run any JGit servers myself), but if we do it in Git, I think that is the path we should go for maximum compatibility (and then if we jump to protocol v2, we get to shed all of the compatibility cruft). > This allows the fetch-pack client to bypass a very large advertisement > if it wants only a specific SHA-1 and doesn't care about the ref name > its bound to, or reachable through. Yep, definitely a useful thing. > This is also perhaps a stepping stone towards "client speaks first". > If we can later standardize an HTTP query parameter or extra HTTP > header, the server may be able to avoid sending a lot of ref > advertisements, but would still need to advertise capabilities. Yes, but that is a big enough jump that we can design it to look like whatever we want, not shoe-horning it into a pretend ref. Older clients will be left behind either way, we will need a transition plan, etc. -Peff