On Fri, Aug 21, 2015 at 12:51 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Aug 21, 2015 at 12:48:23PM -0700, Stefan Beller wrote: > >> > Before even looking at the implementation, my first question would be >> > whether this pattern is applicable in several places in git (i.e., is it >> > worth the extra complexity of abstracting out in the first place). I >> > think there are a few task-queue patterns already in git; for example >> > the delta search in pack-objects. Is the interface given here sufficient >> > to convert pack-objects? Is the result nicer to read? Is it as >> > efficient? >> > >> > We do not need to convert all possible call-sites to the new abstracted >> > code at once. But I find that converting at least _one_ is a good litmus >> > test to confirm that a new interface is generally useful. >> >> Ok, I'll head off to convert one place. > > Thanks. By the way, reading over what I wrote, it sounds a little > harsher than I meant. It did not sound harsh at all. I was just reading an internal mailing list, which cites over generalizing as a very bad practice worse than premature optimization, so I totally understand your concern and agree. > It is not "if you do not convert an existing site, > we cannot accept a new interface, period". But I would like at least > some explanation as an alternative, like "I'm pretty sure we can convert > site X to this, but it is not a good time to do so now because of Y". > Where "Y" might be "we need to do this other refactoring work first", or > "it would be disruptive to other work in the area". > > -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