Felipe Contreras <felipe.contreras@xxxxxxxxx> 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. >> ... 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. -- 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