On Mon, Mar 05, 2018 at 10:29:14AM -0800, Jonathan Nieder wrote: > >> It also accepts "refs/h*" to get "refs/heads" and "refs/hello". I think > >> it's worth going for the most-restrictive thing to start with, since > >> that enables a lot more server operations without worrying about > >> breaking compatibility. > > > > And just to clarify what do you see as being the most-restrictive case > > of patterns that would should use? > > Peff, can you say a little more about the downsides of accepting > refs/h*? > > IIRC the "git push" command already accepts such refspecs, so there's a > benefit to accepting them. Reftable and packed-refs support such > queries about as efficiently as refs/heads/*. For loose refs, readdir > doesn't provide a way to restrict which files you look at, but loose > refs are always slow anyway. :) > > In other words, I see real benefits and I don't see much in the way of > costs, so I'm not seeing why not to support this. "git for-each-ref" only handles "/" boundaries. I think we used to have similar problems with the internal for_each_ref(), but I just checked and I think it's more flexible these days. One could imagine a more trie-like storage, though I agree that is stretching it with a hypothetical. Mostly my point was that I don't see any big upside, and the choice seemed rather arbitrary. And as it is generally easier to loosen the patterns later than tighten them, it makes sense to go with the tightest option at first unless there is a compelling reason not to. -Peff
