Florian Achleitner wrote: > This is how I see it, probably it's all wrong: > I thought the main problem is, that we don't want processes to have *more than > three pipes attached*, i.e. stdout, stdin, stderr, because existing APIs don't > allow it. Oh, that makes sense. Thanks for explaining, and sorry to have been so dense. At the Windows API level, Set/GetStdHandle() is only advertised to handle stdin, stdout, and stderr, so on Windows there would indeed need to be some magic to communicate the inherited HANDLE value to fast-import. But I am confident in the Windows porters, and if a fast-import interface change ends up being needed, I think we can deal with it when the moment comes and it wouldn't necessitate changing the remote helper interface. You also mentioned before that passing fast-import responses to the remote helper stdin means that the remote helper has to slurp up the whole list of refs to import before starting to talk to fast-import. That was good practice already anyway, but it is a real pitfall and a real downside to the single-input approach. Thanks for bringing it up. 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