Re: [PATCH] negotiator/skipping: skip commits during fetch

[Jonathan Tan <jonathantanmy@google.com>]

> > +fetch.negotiationAlgorithm::
> > +	Control how information about the commits in the local repository is
> > +	sent when negotiating the contents of the packfile to be sent by the
> > +	server. Set to "skipping" to use an algorithm that skips commits in an
> > +	effort to converge faster, but may result in a larger-than-necessary
> > +	packfile; any other value instructs Git to use the default algorithm
> > +	that never skips commits (unless the server has acknowledged it or one
> > +	of its descendants).
> > +
> 
> ...let's instead document that there's just the values "skipping" and
> "default", and say "default" is provided by default, and perhaps change
> the code to warn about anything that isn't those two.
> 
> Then we're not painting ourselves into a corner by needing to break a
> promise in the docs ("any other value instructs Git to use the default")
> if we add a new one of these, and aren't silently falling back on the
> default if we add new-fancy-algo the user's version doesn't know about.

My intention was to allow future versions of Git to introduce more
algorithms, but have older versions of Git still work even if a
repository is configured to use a newer algorithm. But your suggestion
is reasonable too.

> Now, running that "git fetch --all" takes ages, and I know why. It's
> because the in the negotiation for "git fetch some/small-repo" I'm
> emitting hundreds of thousands of "have" lines for SHA1s found in other
> unrelated repos, only to get a NAK for all of them.
> 
> One way to fix that with this facility would be to have some way to pass
> in arguments, similar to what we have for merge drivers, so I can say
> "just emit 'have' lines for stuff found in this branch". The most
> pathological cases are when I'm fetching a remote that has one commit,
> and I'm desperately trying to find something in common by asking if the
> remote has hundreds of K of commits it has no chance of having.
> 
> Or there may be some smarter way to do this, what do you think?

Well, there is already a commit in "next" that does this :-)

3390e42adb ("fetch-pack: support negotiation tip whitelist", 2018-07-03)