On 03/05, Jeff King wrote: > On Mon, Mar 05, 2018 at 10:21:55AM -0800, Brandon Williams wrote: > > > > Hmm, so this would accept stuff like "refs/heads/*/foo" but quietly > > > ignore the "/foo" part. > > > > Yeah that's true...this should probably not do that. Since > > "refs/heads/*/foo" violates what the spec is, really this should error > > out as an invalid pattern. > > Yeah, that would be better, I think. > > > > 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? > > I mean only accepting "*" at a "/" boundary (or just allowing a trailing > slash to imply recursion, like "refs/heads/", or even just always > assuming recursion to allow "refs/heads"). For simplicity I'll change ref-patterns to be ref-prefixes where a ref must start_with() one of the provided ref-prefixes. Clients won't send '*'s either but can send everything upto but not including the '*' as a prefix. -- Brandon Williams
