Re: Huge push upload despite only having a tiny change

[Derrick Stolee <stolee@gmail.com>]

On 6/2/2020 3:21 PM, Elijah Newren wrote:
> * The user was two commits behind the closely-related branch at the
> time of the first push, and 10 commits behind at the time of the
> second push.  Running format-patch on these 10 commits that were on
> the server at the time shows their size is at most about ~55 k.

This is most-likely the difference, since the pack-objects algorithm
only looks at the _boundary_ between the server's commits and the
commits-to-push. This also could have dramatically changed the delta-base
matches.

Do you have exact object counts? It would help to know if somehow the
object discovery algorithm is at fault or the delta-base algorithm
is to blame.

For instance, `pack.useSparse` was enabled by default this release,
and has some opportunity to push extra objects. See [1] for more
details on both the "boundary" description (the "commit frontier")
but also how that option changes the algorithm.

The only case I know of that could lead to sending extra objects
(that was not the case before) is described in t5322-pack-objects-sparse.sh
and 4f6d26b1 (list-objects: consume sparse tree walk, 2019-01-16).
It involves doing a full _copy_ of a tree from one position to
another, without "disturbing" the parent of the original tree.

(I mean: copy directory A/B to C/D and make sure nothing is
different in directory A.)

However, if these two pushes were with the same config setting,
I'm not sure what could have changed between the pushes to hit
this very narrow case.

Thanks,
-Stolee


[1] https://devblogs.microsoft.com/devops/exploring-new-frontiers-for-git-push-performance/