Hi again,
Florian Achleitner wrote:
> When the first line arrives at the remote-helper, it starts importing one
> line
> at a time, leaving the remaining lines in the pipe.
> For importing it requires the data from fast-import, which would be mixed
> with
> import lines or queued at the end of them.
Oh, good catch.
The way it's supposed to work is that in a bidi-import, the remote
helper reads in the entire list of refs to be imported and only once
the newline indicating that that list is over arrives starts writing
its fast-import stream. We could make this more obvious by not
spawning fast-import until immediately before writing that newline.
This needs to be clearly documented in the git-remote-helpers(1) page
if the bidi-import command is introduced.
If a remote helper writes commands for fast-import before that newline
comes, that is a bug in the remote helper, plain and simple. It might
be fun to diagnose this problem:
static void pipe_drained_or_die(int fd, const char *msg)
{
char buf[1];
int flags = fcntl(fd, F_GETFL);
if (flags < 0)
die_errno("cannot get pipe flags");
if (fcntl(fd, F_SETFL, flags | O_NONBLOCK))
die_errno("cannot set up non-blocking pipe read");
if (read(fd, buf, 1) > 0)
die("%s", msg);
if (fcntl(fd, F_SETFL, flags))
die_errno("cannot restore pipe flags");
}
...
for (i = 0; i < nr_heads; i++) {
write "import %s\n", to_fetch[i]->name;
}
if (getenv("GIT_REMOTE_HELPERS_SLOW_SANITY_CHECK"))
sleep(1);
pipe_drained_or_die("unexpected output from remote helper before
fast-import launch");
if (get_importer(transport, &fastimport))
die("couldn't run fast-import");
write_constant(data->helper->in, "\n");
--
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
