Re: [RFC 4/4 v3] Add cat-blob report fifo from fast-import to remote-helper.

[Jonathan Nieder <jrnieder@gmail.com>]

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