On Fri, Sep 02, 2016 at 04:51:45PM -0700, Jonathan Nieder wrote: > > I'd be more interested in the pain of this transition if there was a > > concrete use case for "hide literally all refs, but still allow > > fetches". Is that a thing that people do? > > Sure, it is a thing that people do. For example I've seen replication > systems that learn what SHA-1s to fetch out-of-band and then use this > approach to avoid the overhead of a long ref advertisement.
I know that's how those features work. I was more wondering if it ever comes up that somebody actually has hidden refs, but _no_ non-hidden ones. Do the systems you've seen hide all the refs? > However, that is not my motivation. My motivation is being able to > extend the protocol in the future. The capabilities line has been > important for that historically. Sure, I agree it's a nice move forward for compatibility. But that argues for teaching the clients to handle it (for the future), and then turning it on in the server only when it becomes useful (i.e., the "in a year or so" can become "when we find a use for it"). In a similar vein, I'd think that a config to enable this in upload-pack today could have an "auto" mode, which enables it _only_ when you know something productive might come of it (namely that you have hidden refs, one of the uploadpack.allow* features is enabled, and the ref advertisement is empty). Then requests which could not benefit from it at all do not have to pay the potential compatibility cost. > Do you have any objection to the server gaining support for this > guarded by a configuration option? Then when the time comes to > consider flipping the default we can use real-world statistics about > what git client versions people use to make an informed decision. Guarded by config, no. It's the flipping of the default I care more about. The config is not necessary in the meantime for getting real-world statistics; you can add the config and flip the default as one unit at any time (the thing that is time-critical is teaching the client to handle _both_ cases gracefully). The config is useful in the meantime if there are people who could benefit from it immediately, and don't mind paying the compatibility cost. With an "auto" as I described above, using that as the default seems like a decent interim behavior (i.e., why would you set up such a repository if you didn't expect most clients to use the allowTipSHA1 feature?). I'd still probably give some lag between shipping the client, and flipping the server default to "auto". I hoped to share some numbers on what versions people are currently using against GitHub, to get a sense of how far back most people are. But I haven't been actively involved in keeping those numbers for a while, and I'm not sure what we have readily stored. I did show some numbers a few years ago[1], and it looks like about 2/3 of people were within 6-12 months of the latest version, but the rest was a long tail. I don't know if that will have changed with the advent of more client versions (e.g., lots more people are using libgit2 now via GUI clients, Visual Studio, etc; how does it fare with the proposed change?). -Peff [1] http://public-inbox.org/git/20120531114801.ga21...@sigill.intra.peff.net/
