On Tue, Dec 06, 2016 at 09:53:53AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I don't know if that makes things any easier. I feel funny saying "no, > > no, mine preempts yours because it is more maint-worthy", but I think > > that order does make sense. > > > > I think it would be OK to put Brandon's on maint, too, though. It is a > > refactor of an existing security feature to make it more featureful, but > > the way it is implemented could not cause security regressions unless > > you use the new feature (IOW, we still respect the whitelist environment > > exactly as before). > > I think I merged yours and then Brandon's on jch/pu branches in that > order, and the conflict resolution should look OK. > > I however forked yours on v2.11.0-rc1, which would need to be > rebased to one of the earlier maintenance tracks, before we can > merge it to 'next'. Yeah, I built it on top of master. It does depend on some of the http-walker changes Eric made a few months ago. In particular, 17966c0a6 (http: avoid disconnecting on 404s for loose objects, 2016-07-11) added some checks against the HTTP status code, and my series modifies the checks (mostly so that ">= 400" becomes ">= 300"). Rebasing on maint-2.9 means omitting those changes. That preserves the security properties, but means that the error handling is worse when we see an illegal redirect. That may be OK, though. Since the resolution is to omit the changes entirely from my series, merging up to v2.11 wouldn't produce any conflicts. We'd need to have a separate set of patches adding those changes back in. -Peff