On Tue, Jun 16, 2015 at 1:18 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Jun 16, 2015 at 01:14:03PM -0400, Augie Fackler wrote: > >> Yeah, not having it for the push side is a slight bummer, but in >> general I haven't had problems debugging git clients pushing bogus >> data in the same way that I've had problems with weirdness in new >> server features. > > Being in charge of a large git server farm, I think I have the opposite > problem. :) I've got plenty of servers too, but we haven't typically seen push-time problems. Maybe we're lucky, and now that I've said something and tempted Murphy I'll suffer torment. :) > >> > Here's a rough cut at the "trace stdin" idea I mentioned earlier (which >> > is essentially an internal "tee"). You can collect the incoming pack >> > like: >> >> Neat, but not sure I like the extra overhead of having to grab the >> full trace and then reconstruct some arguments to be able to diagnose >> the pack. Having the verbatim pack just land on disk is really handy, >> because then any existing tools one has cooked up (my team has a few >> weird one-off ones by now) just work without extra fussing or looking >> up steps to reconstruct the whole file. > > I guess there is really room for both. Just because you _can_ accomplish > the same thing with both does not mean we cannot have two ways to do it > (an easy way, and a harder, more flexible way). *nod* that might make the most sense - given that we both seem to have use cases in mind for verbatim packs on pulls, that seems like a good thing to have easy to deploy. (It still seems to me more likely to write custom servers than clients, but then again custom VCS servers has been my life for a while, so I likely have a weird perspective on things.) > > -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html