Re: Closing fds twice when using remote helpers

[Mike Hommey <mh@glandium.org>]

On Thu, May 16, 2019 at 05:47:52PM -0400, Jeff King wrote:
> On Thu, May 16, 2019 at 05:35:19PM +0900, Mike Hommey wrote:
> 
> > On Wed, May 15, 2019 at 11:28:02PM -0400, Jeff King wrote:
> > > Totally orthogonal, but I think we might also want to introduce a helper
> > > capability so that import helpers can say "I always send 'done' to
> > > fast-import". And then we can pass "--done" to fast-import, which means
> > > it would detect a truncated stream.
> > 
> > Doubly orthogonal, but I wouldn't mind a helper capability that allows
> > import helpers to deal with creating git objects on their own rather
> > than having a fast-import spawned (git-cinnabar actually doesn't use the
> > fast-import stream it's offered to use, but can't be a fetch helper
> > either)
> 
> Yeah, while writing that I definitely thought "Gee, wouldn't it be
> easier if the importer was just responsible for running fast-import
> itself?".
> 
> What makes it impossible to run as a normal fetch-helper? Is it that we
> expect the helper to then report back the refs for us to update?
> 
> So I take it your strategy is to just run your own fast-import, and then
> you just pass along EOF with no input to the one that Git runs, to
> signal that you're done importing? So maybe the right capability is to
> let the helper say "by the way, I don't need you to run fast-import for
> me". But it's probably not that big a deal, since it's just wasting an
> extra process startup.

When it received the "import" command, git-cinnabar does its stuff,
creates the namespaced refs it advertized in its response to
"capabilities", and writes "done". That's all. So in fact, the current
setup, without --done passed to fast-import, just works.

Mike