Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add batched merge (rollup) feature #46

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

barosl
Copy link

@barosl barosl commented Dec 12, 2014

Currently it works as follows:

  1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
    These commits will have an implicit priority of -1 to postpone the individual merge.
  2. If one of the marked commits reaches the top of the queue, all the marked commits will be merged together and tested.
  3. While merging commits, those commits that fail to merge are ignored.
  4. You can prioritize the rollup by setting p=.

Typical usage:

  1. We have three commits to be tested together.
  2. Set r+ rollup to the first commit.
  3. Set r+ rollup to the second commit.
  4. Set r+ rollup p=10 to the last commit, which will trigger the rollup process soon.

Fixes #34.

Checking if the user is one of the reviewers is already done when
retrieving the head comments.
@barosl barosl force-pushed the rollup branch 3 times, most recently from 271146f to a1d4f5e Compare December 12, 2014 06:10
@barosl
Copy link
Author

barosl commented Dec 12, 2014

You can see the working sample from here: barosltestest/test#49

@barosl
Copy link
Author

barosl commented Dec 12, 2014

By defaults, bors checks the freshness of the merge commit before fast-forwarding it to master. "Fresh" in this case means that the two direct parents of the merge commit is exactly the HEADs of the master branch and the test branch ("auto"), meaning no other commits are pushed to master while testing the candidate.

As a batched merge commit does not have master as a direct parent, the freshness check always fails. So, this PR simply bypasses the check if the pending job is a rollup. This workaround is not elegant, but in reality it wouldn't make a serious problem because the fast-forward itself ensures the freshness.

@barosl barosl force-pushed the rollup branch 6 times, most recently from 5807cf4 to f57c6cc Compare December 12, 2014 09:49
Currently it works as follows:

1. Mark the commits to be merged together as rollup. (e.g. r+ rollup)
   These commits will have an implicit priority of -1 to postpone the
   individual merge.
2. If one of the marked commits reaches the top of the queue, all the
   marked commits will be merged together and tested.
3. While merging commits, those commits that fail to merge are ignored.
4. You can prioritize the rollup by setting p=.

Typical usage:

1. We have three commits to be tested together.
2. Set r+ rollup to the first commit.
3. Set r+ rollup to the second commit.
4. Set r+ rollup p=10 to the last commit, which will trigger the rollup
   process soon.

Fixes graydon#34.
@Gankra
Copy link

Gankra commented Dec 12, 2014

In order for the Rust project to take advantage of this, it would need to be based on the rust branch, which has diverged from master in incompatible ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add PR "rollups"
2 participants