On Mon, Apr 1, 2013 at 11:01 PM, Jeff King <p...@peff.net> wrote:
> On Mon, Apr 01, 2013 at 10:51:20PM -0600, Felipe Contreras wrote:
>> > So in fetch_with_import, we have a remote-helper, and we have a
>> > bidirectional pipe to it. We then call get_importer, which starts
>> > fast-import, whose stdin is connected to the stdout of the remote
>> > helper. We tell the remote-helper to run the import, then we wait for
>> > fast-import to finish (and complain if it fails).
>> >
>> > Then what? We seem to do some more work, which I think is what causes
>> > the errors you see; but should we instead be reaping the helper at this
>> > point unconditionally? Its stdout has presumably been flushed out to
>> > fast-import; is there anything else for us to get from it besides its
>> > exit code?
>> The problem is not with import, since fast-import would generally wait
>> properly for a 'done' status, the problem is with export.
> Your patch modified fetch_with_import. Are you saying that it isn't
> necessary to do so?

It's not, I added it for symmetry. But that's the case *if* the
remote-helper is properly using the "done" feature.

>> Also, the design is such that the remote-helper stays alive, even
>> after fast-export has finished.
> So if we expect to be able to communicate with the remote-helper after
> fast-export has exited, is it a protocol failure that the helper does
> not say "yes, I finished the export" or similar? If so, can we fix that?
> I am not too familiar with this protocol, but it looks like we read from
> helper->out right after closing the exporter, to get the ref statuses.
> Shouldn't we be detecting the error if the helper hangs up there?

I guess that should be possible, I'll give that a try.


Felipe Contreras
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

Reply via email to