Re: [PATCH v3 2/2] transport-helper: check if remote helper is alive

Felipe Contreras [off-list ref] writes:

I'm not talking about the time it took to come up with the criticism
below, I'm talking about the comment regarding the commit message. If
the commit message did indeed provide *zero* explanation, that's
certainly something that should be immediately visible, no? It could
have been mentioned six months ago.

Given that all of your log messages tend to be missing or terser
than necessary, I wouldn't be surprised Peff stopped bothering about
it.

But now we know this needs to be better explained, and your v4 has
better explanation that will help you avoid having to repeat
yourself in the discussion, so let's not dwell on it too much.

quoted

...  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?  How would the process tree and
piping constructed around the current system?

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...

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.

On Mon, Apr 8, 2013 at 1:46 PM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

...  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).

quoted

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.

Cheers.

--
Felipe Contreras