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/
