ilyakooo0/nixpkgs
1
0
Fork 0
mirror of https://github.com/ilyakooo0/nixpkgs.git synced 2024-12-29 14:57:28 +03:00
Code Issues Projects Releases Wiki Activity

CONTRIBUTING.md: simplify rebasing instructions

Browse Source 
Makes the instructions easier to remember (and type) using the
`git rebase --onto A...B` syntax to find the merge base between A and B
(which has been in git for at least 10 years).

We also assume that the merge base between staging and master is also
the merge base between staging and the current branch (since it is based
on master), and giving master as the <upstream> branch makes git
consider the commits in the current branch that are not in master, so
there's no need to compute the merge base between master and the current
branch.

In the same spirit of discouraging copy-and-paste, use a placeholder
name for the current branch instead of `$(git branch --show-current)`.
This commit is contained in:
Naïm Favier 2022-05-29 21:53:19 +02:00
parent e37248668b
commit d2990717f1
No known key found for this signature in database
GPG Key ID: 49B07322580B7EE2
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
CONTRIBUTING.md
View File

@ -62,25 +62,26 @@ 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 rebasing should not be performed directly on the target branch, but on the merge
base between the current and target branch. base between the current and target branch.
In the following example, we see a rebase from `master` onto the merge base In the following example, we assume that the current branch, called `feature`,
between `master` and `staging`, so that a change can eventually be retargeted to is based on `master`, and we rebase it onto the merge base between
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git` `master` and `staging` so that the PR can eventually be retargeted to
while the `origin` remote is used for the remote you are pushing to. `staging` without causing a mess. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
while `origin` is the remote you are pushing to.
```console ```console
# Find the common base between two branches # Rebase your commits onto the common merge base
common=$(git merge-base upstream/master upstream/staging) git rebase --onto upstream/staging... upstream/master
# 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 # Force push your changes
git push origin $(git branch --show-current) --force-with-lease git push origin feature --force-with-lease
``` ```
The syntax `upstream/staging...` is equivalent to `upstream/staging...HEAD` and
stands for the merge base between `upstream/staging` and `HEAD` (hence between
`upstream/staging` and `upstream/master`).
Then change the base branch in the GitHub PR using the *Edit* button in the upper 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 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 retargeted it might be necessary to do a final rebase onto the target branch, to
resolve any outstanding merge conflicts. resolve any outstanding merge conflicts.
@ -90,7 +91,7 @@ git rebase upstream/staging
# Review and fixup possible conflicts # Review and fixup possible conflicts
git status git status
# Force push your changes # Force push your changes
git push origin $(git branch --show-current) --force-with-lease git push origin feature --force-with-lease
``` ```
## Backporting changes ## Backporting changes