Skip to content

CONTRIBUTING: rebase master to staging without pinging people #166472

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.

Sign up for GitHub

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

Merged
Mic92 merged 2 commits into from
Apr 4, 2022
Merged

CONTRIBUTING: rebase master to staging without pinging people #166472

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
af8c598
CONTRIBUTING: rebase master to staging without pinging people
Mic92 Mar 30, 2022
0f4a2f1
fixup! CONTRIBUTING: rebase master to staging without pinging people
mweinelt Apr 3, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,46 @@ In addition to writing properly formatted commit messages, it's important to inc

For package version upgrades and such a one-line commit message is usually sufficient.

## Rebasing between branches (i.e. from master to staging)

From time to time, changes between branches must be rebased, for example, if the
number of new rebuilds they would cause is too large for the target branch. When
rebasing, care must be taken to include only the intended changes, otherwise
many CODEOWNERS will be inadvertently requested for review. To achieve this,
rebasing should not be performed directly on the target branch, but on the merge
base between the current and target branch.

In the following example, we see a rebase from `master` onto the merge base
between `master` and `staging`, so that a change can eventually be retargeted to
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
while the `origin` remote is used for the remote you are pushing to.


```console
# Find the common base between two branches
common=$(git merge-base upstream/master upstream/staging)
# Find the common base between your feature branch and master
commits=$(git merge-base $(git branch --show-current) upstream/master)
# Rebase all commits onto the common base
git rebase --onto=$common $commits
# Force push your changes
Copy link
Member

@dasJ dasJ Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# Force push your changes
# Force push your changes
git fetch upstream staging
git rebase upstream/staging

Copy link
Contributor

@jonringer jonringer Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this shouldn't be necessary since they should have done git rebase --onto=$common $commits

Copy link
Member

@piegamesde piegamesde Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebasing onto upstream/staging should only be done after having force-pushed and switched the target branch in GitHub (see #166472 (comment)). (I may be misunderstanding your suggestion though)

Copy link
Member

@mweinelt mweinelt Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The merge base between master and staging is usually older than staging itself, and in between that diff there may be conflicting changes still.

Copy link
Contributor

@jonringer jonringer Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yea, that's fair. Keep forgetting about divergence :(

git push origin $(git branch --show-current) --force-with-lease
```

Then change the base branch in the GitHub PR using the *Edit* button in the upper
right corner, and switch from `master` to `staging`. After the PR has been
retargeted it might be necessary to do a final rebase onto the target branch, to
resolve any outstanding merge conflicts.

```console
# Rebase onto target branch
git rebase upstream/staging
# Review and fixup possible conflicts
git status
# Force push your changes
git push origin $(git branch --show-current) --force-with-lease
```

## Backporting changes

Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
Expand Down