Switching the base branch without causing a mess?
primeos opened this issue · comments
I was wondering if there's a way to switch the base branch on a Nixpkgs PR without triggering CI? The problem is that one cannot (AFAIK) simultaneously switch the base branch and update the branch to be merged. Therefore a much bigger diff will exist for a short time-frame and ofborg is usually so fast that the evaluation will already have started. As a result ofborg will unnecessarily ping some maintainers and potentially change a lot of labels.
If there isn't already a way to avoid it, one of the following solution might be possible:
- Ignore events where the base branch is changed
- Workflow: Change the base branch -> update the branch to be merged (which should still trigger a rebuild)
- Disadvantage: Only works using the above order
- Add another tag/label (similar to
[WIP]/2.status: work-in-progress) that disables CI completely- Workflow: Add the tag/label -> make the change -> remove the tag/label
- Disadvantages: More complicated for a user and label changes require commit access
- Wait a bit until triggering CI
- Workflow: Unchanged, at least if one is fast enough to make both changes in the given time-frame
- Disadvantage: Might be more difficult to implement, especially if
ofborguses information from GitHub events / web-hooks (I haven't checked the source-code)
PS: I hope the title of this issue isn't offensive, I really like and appreciate ofborg ❤️ (I just couldn't figure out a better title :o)
A very manual way to do this:
- rebase/move your commits on top of the merge-base of the current branch and the newly wanted base. This way the PR will look the same from both bases.
- force push
- freely switch base on the PR
But, yeah, would be cool if ofborg could gain some functionality to make this less painful.
@hedning awesome, I would've never thought of this :)
If I understand the first step correctly I'd basically do something like this?:
UPSTREAM=origin # Name of the NixOS/nixpkgs remote
OLD_BASE_BRANCH=master
NEW_BASE_BRANCH=staging
PR_COMMIT=$(git rev-parse HEAD) # Commit one wants to be merged
git fetch $UPSTREAM # Optional
MERGE_BASE=$(git merge-base $UPSTREAM/$OLD_BASE_BRANCH $UPSTREAM/$NEW_BASE_BRANCH)
# Since a rebase will probably only in rare cases work as desired for this
# (since $MERGE_BASE is probably older than HEAD):
git reset --hard $MERGE_BASE # Careful, will discard any uncommitted changes!
git cherry-pick $PR_COMMIT
# TODO: git push $FORK HEAD:$PR_BRANCHAssuming only a single commit to be merged, no merge conflicts, and a single merge base (as well as no typos/errors in my untested (should work) "script").
Yep, that's the idea. As you say rebase might not work (magit have a rebase subset option that might work), so cherry-picking is probably the more general option.
At the moment, I can't think of a nice way to implement this (though it has only been a little while). Maybe in the mean time, those instructions (or something similar) could go in Nixpkgs' CONTRIBUTING document, like the instructions for backporting are? It would at least help for the majority of cases that I think are "only a single commit to be merged, no merge conflicts, and a single merge base," as you point out.
Another potential solution that wouldn't completely get rid of the ping spam might be to remove reviewers that were automatically requested due to a messy branch change? A drawback might be accidentally removing manually-requested reviewers, though, and the heuristics determining when to remove would have to be rock-solid.
Maybe for your "wait a bit" idea, this could only be triggered on PRs that exceed a certain number of commits and/or LOC delta? E.g. if a PR contains, say, 50 commits or 500 LOC delta, wait 5 seconds before triggering? Heuristics would need to be discussed and determined to be rock-solid, but it might be worth looking at.
Overall, I agree. The current spamming of involved persons when changing the base branch is not ideal.
An alternative would be #66 and include merge-base instructions in the warning message. That doesn't really solve the problem but at least makes people aware of how to avoid it in most cases.
This was partially resolved by #488, at least requesting reviews should be skipped in most cases now.
@LnL7 awesome, thanks :)
I guess it would be nice to have #463 (comment) as well or an @ofborg command for maintainers to switch the base branch, but that's obviously completely optional. For me this issue is already resolved by the merge-base trick (#463 (comment)) so we can also close this issue if wanted.
Yep, that's the idea. As you say rebase might not work (magit have a rebase subset option that might work), so cherry-picking is probably the more general option.
git rebase --onto "$MERGE_BASE" "$OLD_BASE_BRANCH" should always work, no?
I just learned by reading the manual that --onto has a feature to find the merge base between two branches, so the entire thing can be reduced to
git rebase --onto "$new_base"... "$old_base"
(leaving the right hand side of ... empty means HEAD, or equivalently here old_base)
Magic!
The way is now documented in https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#rebasing-between-branches-ie-from-master-to-staging