Re: git.git as of tonight

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 3, 2015, 17:05 UTC
Message-ID: <xmqq37wndndp.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <56385587.1010601@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

> My findings so far are negative. The only short-term and mid-term
> solution I see so far is to opt-out from the framework during
> build-time.

Now, from where I sit, it seems that the way forward would be

 1. Make this an optional feature so that platforms can compile it
    out, if it is not already done.  My preference, even if we go
    that route, would be to see if we can find a way to preserve the
    overall code structure (e.g. instead of spawning multiple
    workers, which is why the code needs NONBLOCK to avoid getting
    stuck on reading from one while others are working, perhaps we
    can spawn only one and not do a nonblock read?).

 2. After that is done, the feature could graduate to 'master'.  As
    this is a bigger framework change than others, however, we do
    not necessarily want to rush it.  On the other hand, because
    this only affects submodules, which means it has fewer users and
    testers that would give us feedback while it is on 'next', we
    may want to push it to 'master' sooner to give it a larger
    exposure.  I dunno, and I do not want to decide this myself the
    week before I'll go offline for a few weeks (i.e. today).

 3. Then we would enlist help from folks who are more familiar with
    Windows platform (like you) to see how the "run parallel workers
    and collect from them" can be (re)done with a nice level of
    abstraction.  I am hoping that we can continue the tradition of
    the evolution of run-command.c API (I am specifically impressed
    by what you did for "async" that allows the callers not to worry
    about threads and processes) aroundt this area.  That is
    obviously a mid- to longer term goal.

Thanks for working together well, you two.