Subject: Re: [PATCH 2/2] upload-pack: don't ACK non-commits repeatedly in protocol v2

From: Patrick Steinhardt <[email-masked]>
Date: Fri, 5 Sep 2025 08:11:49 +0200

On Thu, Sep 04, 2025 at 09:37:58AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> writes:
> 
> > ... when the
> > server ACKs an object there is no reason for the client to go deeper, so
> > they stop advertising any of its parents.
> 
> Very true.  I did point out the difference in behaviour, but I
> couldn't actually figure out what goodness we are deriving in this
> code by marking grandparents (and possibly their ancestors) as
> something they have.  Your change in behaviour could be seen as
> stopping us from making unnecessary operations ;-)
> 
> If the other side is mischievous, they are not limited to feed us a
> commit and then its parent in the naturally expected order.  They
> could feed us A and then skip B and give us C that is a child of B.
> Pre-painting B when we got A from them, in order to prepare for
> seeing B (which we can return without doing anything) in the next
> round, would not help us all that much, if they give us C after
> giving us A, as we haven't even heard of C yet at that point.

Yeah, it _feels_ like the change should be fine overall. But honestly, I
feel more comfortable with keeping the status quo for now so that the
change is only doing what it's advertised to do, namely cull the memory
growth.

So I'll apply the patch I had and send a v2, but we may think about the
other angle as a #leftoverbit.

> But in the normal case against sane clients that do not skip the
> probes, marking immediate parents (like B) when processing A might
> be helping?  I dunno.  I also somehow thought that even normal case
> we have an option to skip the probes in order to converge faster,
> but I am misremembering.
> 
> cf. https://lore.kernel.org/git/?q=upload-pack%20fibonacci

You probably mean `fetch.negotiationAlgorithm=skipping`?

Patrick