[snip] > > in which we have rarely-updated branches that we still want to fetch > > (e.g. an annotated tag when we fetch refs/tags/* or a Gerrit > > refs/changes/* branch), having the ref advertisement first means that we > > can omit them from our "want" or "want-ref" list. But not having them > > means that we send "want-ref refs/tags/*" to the server, and during > > negotiation inform the server of our master branch (A), and since the > > server knows of a common ancestor of all our wants (A, B, C), it will > > terminate the negotiation and send the objects specific to branches B > > and C even though it didn't need to. > > > > So maybe we still need to keep the ls-refs step around, and thus, this > > design of only accepting exact refs is perhaps good enough for now. > > I think that taking a smaller step first it probably better. This is > something that we've done in the past with the shallow features and > later capabilities were added to add different ways to request shallow > fetches. I think we're agreeing that the smaller step first is better. > That being said, if we find that this feature doesn't work as-is and > needs the extra complexity of patterns from the start then they should > be added. I agree (although I would be OK too if we decide to do the small exact-name step now and then the pattern step later guarded by a capability, as long as the project understood that multiple support levels would then exist in the wild). > But it doesn't seem like there's a concrete reason at the > moment. I agree. I thought I had a reason, but not after thinking through the ideas I explained in [1]. [1] https://public-inbox.org/git/20180615190458.147775-1-jonathantanmy@xxxxxxxxxx/
