Last modified: 2013-04-12 18:45:47 UTC
To keep the history in git linear and avoids merges it is necessary to rebase before (fast-forward) merge a commit into git. This is not happen all the time by all reviewers. So please disable Code-Review+2 for non current patch sets or let jenkins rebase before merge, when needed. The last one makes it necessary, that a rebase by jenkins keeps all Code-Review+1 and Code-Review+2, so jenkins can merge it after the tests passed. Thanks.
Tentatively moving to Git/Gerrit, might need to be under Testing Infrastructure for Jenkins though.
We could change the merge strategy to fast-forward only, which would mean there's an implicit rebase by Gerrit before merging (as long as it can).
This is not always desired. The problem would be separating those cases where the parent commit doesn't matter (it's just noise) from those where it does.
Marking this as WONTFIX. * For MediaWiki core (and any other high-traffic repositories), doing this creates pointless rebases and wastes developer time. We tried it with the puppet repo, and quickly changed it back. * For any other repo that doesn't change frequently or only has a few authors, the project owner can change the merge strategy themselves.
