7854219e48
Compared with simply walking the commits with JGit, running Gerrit commit validators is quite expensive. When pushing a large number of commits directly to a branch, validation may exceed the timeout allowed by AsyncReceiveCommits. For example, pushing the full Linux kernel history of 650k commits allows only 370 microseconds of validation time per commit, if validation is allowed to take up the full 4 minute default AsyncReceiveCommits limit. Gerrit's validators have never been particularly optimized, so it wouldn't be entirely surprising to see a timeout in this case, particularly if the Gerrit server is under moderate to heavy load. Add a limit configured with receive.maxBatchCommits, analogous to the existing receive.maxBatchChanges. The options are still separate: maxBatchChanges is about creating changes, which is a far more heavyweight operation as it needs to write change metadata, and accidentally pushing too many changes is a bigger mess to clean up. Change-Id: I4b81b1f99d9dafdc365ff66e0fb812877355e3b9
21 lines
629 B
Plaintext
21 lines
629 B
Plaintext
= too many commits
|
|
|
|
This error occurs when a push directly to a branch
|
|
link:user-upload.html#bypass_review[bypassing review] contains more commits than
|
|
the server is able to validate in a single batch.
|
|
|
|
The recommended way to avoid this message is to use the
|
|
link:user-upload.html#skip_validation[`skip-validation` push option]. Depending
|
|
on the number of commits, it may also be feasible to split the push into smaller
|
|
batches.
|
|
|
|
The actual limit is controlled by a
|
|
link:config-gerrit.html#receive.maxBatchCommits[server config option].
|
|
|
|
GERRIT
|
|
------
|
|
Part of link:error-messages.html[Gerrit Error Messages]
|
|
|
|
SEARCHBOX
|
|
---------
|