On Mon, Apr 8, 2013 at 1:46 PM, Junio C Hamano <gitster@xxxxxxxxx> 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. Cheers. -- Felipe Contreras -- 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