Re: [RFC PATCH] Modify fetch-pack to no longer die on error?

From: Jeff King <peff@peff.net>
Date: Jul 29, 2020, 19:29 UTC
Message-ID: <20200729192915.GA2351724@coredump.intra.peff.net>
In-Reply-To: <20200729185347.653706-1-jonathantanmy@google.com>

On Wed, Jul 29, 2020 at 11:53:47AM -0700, Jonathan Tan wrote:

Show 9 quoted lines

> > This is definitely true sometimes, but I think is sometimes the
> > opposite. When we push things out to a sub-process, then the interface
> > between the two processes has to be well-defined (e.g., writing results
> > to a file with a particular format). And that can make debugging easier,
> > because you can pick up from that intermediate state (munging it in the
> > middle, or even generating it from scratch for testing).
> 
> Well, unless there is some sort of interactivity like in remote helpers
> :-)

Yes, debugging remote helpers is its own special hell. :)

Show 12 quoted lines

> > That said, I think I could buy the argument that "fetch" works pretty
> > well as a basic building block for users. It's pretty rare to actually
> > use fetch-pack as a distinct operation. This is all a monolith vs module
> > tradeoff question, and the tradeoff around modularity for fetch isn't
> > that compelling.
> 
> If we are going the sub-process route, I was planning to use "fetch" as
> the sub-process, actually, not "fetch-pack" - among other things,
> "fetch" allows us to specify a fetch negotiator. So it seems like you
> are saying that if we had to use "fetch-pack", you have no problem with
> libifying it and calling it in the same process, but if we can use
> "fetch", we should use it as a sub-process?

No, I just meant that in general fetching is a monolithic operation from the users perspective, and we don't often need to break it down further. So if you have to build more options into "fetch" (that _could_ have been broken out into separate sub-commands) I don't think anybody will be sad.

I guess that is kind of orthogonal to your original problem, though, which is "should fetch be triggered in-process by other processes". So one could still make the argument that whatever features are needed by that calling code (e.g., "use a different negotiation scheme") might also be needed by other (script) callers of git-fetch, so there may be some benefit to users in making the cross-process interface more rich (of course in the case of negotiation schemes, it is not "make it more rich now" but "earlier efforts to make it rich are now paying off").

-Peff