Re: [RFC PATCH 2/3] run-commands: add an async queue processor
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 21, 2015, 20:41 UTC
- Message-ID
- <xmqq37zc5q8l.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20150821194454.GB26466@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 23 quoted lines
> On Fri, Aug 21, 2015 at 12:05:13PM -0700, Junio C Hamano wrote: > >> The primary reason I suspect is because you sent to a wrong set of >> people. Submodule folks have largely been working in the scripted >> ones, and may not necessarily be the ones who are most familiar with >> the run-command infrastructure. >> >> "shortlog --no-merges" tells me that the obvious suspects are j6t >> and peff. > > No good deed goes unpunished. ;) > > 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.
Ah, thanks for saying this. I recall saying something similar earlier and totally agree with you.