Re: [PATCH v2 2/2] connect: advertized capability is not a ref

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 2, 2016, 23:51 UTC
Message-ID: <20160902235145.GI14758@google.com>
In-Reply-To: <20160902233547.mzgluioc7hhabalw@sigill.intra.peff.net>

Jeff King wrote:

> On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:

>                                  But combining hideRefs with
> allowTipSHA1InWant could trigger this case.

Yes.

[...]

> 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.

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.

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.

Thanks, Jonathan