Page MenuHomePhabricator

Allow pushing more than 10 changes at once
Closed, DeclinedPublic

Description

I got the following error yesterday:

! [remote rejected] HEAD -> refs/publish/master/ContLang (the number of pushed changes in a batch exceeds the max limit 10)

I wrote a bunch of patches that depended on each other and tried to push an updated version, but it failed because there were 11. I worked around it by making a new branch that omitted one of the patches (that subsequent patches didn't depend on). I would like to not have to do this. I tend to appear briefly and write lots of code in a short time that takes a while to get reviewed, so this will be a constant problem for me.

This is apparently controlled by receive.maxBatchChanges, which is supposed to have a default of 0 (no limit). If we want to set it to something other than 0, could it be like 30 or 50?

Event Timeline

Originally caused by:

https://github.com/wikimedia/puppet/commit/9e886b760ac6d3774e7d51ee9dea18678ae1b9be

Is the changes/push limit necessary, or could we do with just the object size limit and get rid of the max changes limit entirely? The commit message doesn't explain why it was necessary. The commit that added this feature to Gerrit said it's meant to prevent accidentally pushing a zillion changes when pushing from a different repo or something:

https://gerrit.googlesource.com/gerrit/+/e13b65d8d58364148540bd273c6e983ea2bc8d9d%5E!/

hashar subscribed.

https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/447821/ introduces the ContentLanguage, its parent looks unrelated ( https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/447788/ use MagicWordFactory ).

Then you just pill up the patches on top of each other to migrate to ContentLanguage in one long chain of dependencies when really they could be merged in any order.

Instead, you could have a patch introducing the new feature. Then craft patches that are directly depending on it.

The limit has a purpose, a very long list of dependencies would end up overloading the CI system.

What about a long dependency list causes extra load, relative to the same set of patches submitted with fewer dependencies? The CI system still has to run all the same tests for each patch.

I should add -- there are cases where there's a final patch that actually depends on all the previous ones. This happens when a number of patches are needed to clean up or port existing code to enable some sort of breaking change, like a hard deprecation. In these cases it's possible to hack around the problem using Depends-On, but that will still cause a long list of dependencies.

For the record, I keep running into this. I'm doing a lot of refactoring work, and if I don't build all my patches on each other there are inevitably merge conflicts. I've been forced to just submit different sets of patches separately and work out the merge conflicts later.

You can work around this by not using git review and a couple of steps...

git push origin HEAD~5:refs/for/master

And then just swap ~5 to a number to split your commits into batches of < 10