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
