Hi,
Some quick details.
Florian Achleitner wrote:
> Anyways, specifying cat-blob-fd is not
> allowed via the 'option' command (see Documentation and 85c62395).
> It wouldn't make too much sense, because the file descriptor must be set up
> by
> the parent.
>
> But for the fifo, it would, probably.
More precisely, requiring that the cat-blob fd go on the command line
instead of in the stream matches a model where fast-import's three
standard streams are abstract:
- its input, using the INPUT FORMAT described in git-fast-import(1)
- its standard output, which echoes "progress" commands
- its backflow stream, where responses to "cat-blob" and "ls" commands go
The stream format is not necessarily pinned to a Unix model where
input and output are based on filesystems and file descriptors. We
can imagine a fast-import backend that runs on a remote server and the
transport used for these streams is sockets; for fast-import frontends
to be usable in such a context, the streams they produce must not rely
on particular fd numbers, nor on pathnames (except for mark state
saved to relative paths with --relative-marks) representing anything
in particular.
This goes just as much for a fifo set up on the filesystem where the
fast-import backend runs as for an inherited file descriptor. In the
current model, such backend-specific details of setup go on the
command line.
> The backward channel is only used by
> the
> commands 'cat-blob' and 'ls' of fast-import. If a remote helper wants to use
> them, it would could make fast-import open the pipe by sending an 'option'
> command with the fifo filename, otherwise it defaults to stdout (like now)
> and
> is rather useless.
I'm getting confused by terminology again. Let's see if I have the cast
of characters straight:
- the fast-import backend (e.g., "git fast-import" or "hg-fastimport")
- the fast-import frontend (e.g., "git fast-export" or svn-fe)
- git's generic foreign VCS support plumbing, also known as
transport-helper.c
- the remote helper (e.g., "git remote-svn" or "git remote-testgit")
Why would the fast-import backend ever need to open a pipe? If I want
it to write backflow to a fifo, I can use
mkfifo my-favorite-fifo
git fast-import --cat-blob-fd=3 3>my-favorite-fifo
If I want it to write backflow to a pipe, I can use (using ksh syntax)
cat |&
git fast-import --cat-blob-fd=3 3>&p
> This would take the fifo setup out of transport-helper. The remote-helper
> would
> have to create it, if it needs it.
We can imagine transport-helper.c learning the name of a fifo set up by
the remote helper by sending it the "capabilities" command:
git> capabilities
helper> option
helper> import
helper> cat-blob-file my-favorite-fifo
helper> refspec refs/heads/*:refs/helper/remotename/*
helper>
transport-helper.c could then use that information to invoke
fast-import appropriately:
git fast-import --cat-blob-fd=3 3>my-favorite-fifo
But this seems like pushing complication onto the remote helper; since
there is expected to be one remote helper per foreign VCS,
implementing the appropriate logic correctly once and for all in
transport-helper.c for all interested remote helpers to take advantage
of seems to me like a better policy.
> Apropos stdout. That leads to another idea. You already suggested that it
> would be easiest to only use FDs 0..2. Currently stdout and stderr of fast-
> import go to the shell. We could connect stdout to the remote-helper and
> don't
> need the additional channel at all.
The complication that makes this strategy not so easy is "progress"
commands in the fast-import input stream. (Incidentally, it would be
nice to teach transport-helper.c to display specially formatted
"progress" commands using a progress bar some day.)
Hoping that clarifies,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
