Hi, Florian Achleitner wrote: > On Windows, processses are not forked but spawned from new and therefore can't > inherit pipe file descriptors. Ok, this is what I didn't understand (and still don't understand). Yes, on Windows processes are spawned instead of forked. But does that mean they can't inherit pipes? How do pipelines in the shell work at all, then? I thought what Hannes said was rather that the current C runtime used by Git for Windows doesn't take care of inherited file descriptors, period, other than 0, 1, and 2. This has nothing to do with the fork/spawn distinction. So while --cat-blob-fd or some other mechanism could be made to work on Windows in the future, *relying* on --cat-blob-fd on Windows today is a no-go, since it rely on file descriptors >2 and break the remote helper infrastructure completely there. That does not force us into a corner at all. We have multiple options. Here is what I propose: Remote helpers declare using a capability (e.g., "bidi-import") that they would like a bidirectional communication channel with fast-import. Git tells the remote helper that its request has been granted by using a different command (e.g., "bidi-import") instead of "import" to start the import process. The responses from fast-import come on stdin (file descriptor 0), so in principle it should be possible to implement this interface on Windows. The interface is portable, even if the initial implementation isn't. Existing remote helpers using the "import" capability would be unaffected and would work as before. On Windows, Git would not take advantage of the bidi-import capability for now. Windows support is an added complication and we have enough to do this summer. Then interested people using Windows would be able to experiment using whatever mechanism they please (CRT support for inherited file descriptors >2, fifos, sockets, some other Windows-specific thing) to implement the bidi-import capability. Once that is implemented, they automatically get support for remote helpers that rely on the bidirectional communication functionality. What do you think? Thanks for explaining, Jonathan -- 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