Hi again, Florian Achleitner wrote:
> Another alternative would be to use the existing --cat-pipe-fd argument. But > that requires to open the fifo before execing fast-import and makes us > dependent on the posix model of forking and inheriting file descriptors Let me elaborate on this, which I think is the real point (though I could easily be wrong). Probably instead of just sending feedback I should have been sending suggested patches to compare. You do not work for me and your time is not my time, and I would not want to have the responsibility of dictating how your code works, anyway. Generally speaking, as long as code is useful and not hurting maintainability, the best thing I can do is to make it easy to incorporate. That has side benefits, too, like giving an example of what it is like to have your code incorporated and creating momentum. Small mistakes can be fixed later. Unfortunately here we are talking about two interfaces that need to be stable. Mistakes stay --- once there is a UI wart in interfaces people are using, we are stuck continuing to support it. To make life even more complicated, there are two interfaces involved here: - the remote-helper protocol, which I think it is very important to keep sane and stable. Despite the remote-helper protocol existing for a long time, it hasn't seen a lot of adoption outside git yet, and complicating the protocol will not help that. I am worried about what it would mean to add an additional stream on top of the standard input and output used in the current remote-helper protocol. Receiving responses to fast-import commands on stdin seems very simple. Maybe I am wrong? - the fast-import interface, which is also important but I'm not as worried about. Adding a new command-line parameter means importers that call fast-import can unnecessarily depend on newer versions of git, so it's still something to be avoided. Given a particular interface, there may be multiple choices of how to implement it. For example, on Unix the remote-helper protocol could be fulfilled by letting fast-import inherit the file descriptor helper->in, while on Windows it could for example be fulfilled by using DuplicateHandle() to transmit the pipe handle before or after fast-import has already started running. The implementation strategy can easily be changed later. What is important is that the interface be pleasant and *possible* to implement sanely. Hoping that clarifies a little, Jonathan -- 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
