On Mon, Apr 8, 2013 at 1:46 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> ... But if we keep
>>> helper running, who will be communicating with it via these open
>>> pipes? The process that is calling finish_command() on fast-import
>>> and disconnecting from the helper won't be, as read/write to the
>>> pipe, even if we do not disconnect from here, will result in errors
>>> if the helper has already exited at this point.
>> Nobody will send any further input, but in theory we could redirect
>> the pipe and send more commands. That's how it was designed.
> Who does the redirection to whom?
The one that is doing all the redirections, transport-helper.
> How would the process tree and
> piping constructed around the current system?
I cannot parse that correctly, but transport-helper is already
receiving the output from the remote-helper.
> I am not trying to say it is just theoretical mental exercise (which
> I have seen you do not do at all on this list). I am trying to find
> out what the practical use case is that you have in mind, because
> disconnecting will prove to be not an improvement but a regression
> for that use case. But you do not have to answer this question
> directly, because...
As the gitifyhg developers effusively pointed out, it's useful to see
which mercurial revision corresponds to certain git revision, and this
is best achieved through notes. Implementing this in the remote-helper
doesn't make much sense (I won't go into details).
>> And in fact, I'm thinking doing exactly that, so we can send another
>> command to fetch the foreign commit ids and append notes with them.
> ...we will see the answer in that change anyway.
That doesn't change the fact that transport-helper would end up with
mixed and matched design. Maybe the use-case above wouldn't be
prevented by this change, but I think further changes would need to be
done to the file to not end up in this weird state.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html