Hi,
I had a user report that two nearly identical pushes (the second being
an amended commit of the first) took dramatically differing amounts of
time and amount of data uploaded (from 4.5 seconds and about 21k
uploaded, to 223 seconds and over 100 MB uploaded).
I'm curious if this might be a known issue; it sounds similar to some
push protocol discussion I remember from the contributor's summit (but
I don't know anything on the protocol side and tend to work on other
things during protocol discussion). If this does sound like a known
issue, does anyone have links to some relevant discussion I can read
up on (and perhaps pass long to this user)? If it doesn't sound like
a known issue, what other things would be useful for me to dig up?
Additional details:
* Both pushes involved cases where the user had a single commit that
the server didn't.
* The parent of the commit that needed to be pushed was the same in both cases.
* The commit in question was small; modifying either 13 or 15 lines of
two files that were each less than about 8k in size.
* The user was pushing up a new branch each time, but the new branch
was closely related to an existing branch (i.e. had all but a few
commits of history in common)
* 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.
* The server has a huge number of refs; about 470k of them (most of
them related to code reviews).
* The server was running Gerrit 3.1.4 (i.e. jgit).
* The user was using a version of git based off master from a few
weeks ago, in particular, with a few changes on top of commit
b994622632 ("The eighth batch", 2020-05-08). I don't think the few
internal changes could affect anything here, but those changes were:
(1) making features.experimental default to true (which only turns on
two fetch settings as far as I can tell), (2) making
merge.directoryRenames default to true, and (3) setting a few trace2.*
config settings by default.
Thanks,
Elijah
