maxmustermann/dogecoin
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge #18283: doc: Explain rebase policy in CONTRIBUTING.md

Browse source 
fa1244783c doc: Explain rebase/squash policy in CONTRIBUTING.md (MarcoFalke)

Pull request description:

ACKs for top commit:
  hebasto:
    re-ACK fa1244783c, typos fixed.
  laanwj:
    ACK fa1244783c

Tree-SHA512: b8f790a8ffa4f59f26b64befbea8acd92f3c548e577c35750a60dde94b4340258a540ad0db60a6de650db0156cbff9e1330c589c300db5253531fe6a16cdbcc9
This commit is contained in:
Wladimir J. van der Laan 2020-03-11 15:57:20 +01:00
parent 2926cbcebb fa1244783c
commit 414f6c496d
No known key found for this signature in database
GPG key ID: 1E4AED62986CD25D
1 changed files with 19 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
CONTRIBUTING.md
View file

@ -117,12 +117,12 @@ At this stage, one should expect comments and review from other contributors. Yo
can add more commits to your pull request by committing them locally and pushing
to your fork until you have satisfied all feedback.
Note: Code review is a burdensome but important part of the development process, and as such, certain types of pull requests are rejected. In general, if the **improvements** do not warrant the **review effort** required, the PR has a high chance of being rejected. It is up to the PR author to convince the reviewers that the changes warrant the review effort, and if reviewers are "Concept NAK'ing" the PR, the author may need to present arguments and/or do research backing their suggested changes.
Note: Code review is a burdensome but important part of the development process, and as such, certain types of pull requests are rejected. In general, if the **improvements** do not warrant the **review effort** required, the PR has a high chance of being rejected. It is up to the PR author to convince the reviewers that the changes warrant the review effort, and if reviewers are "Concept NACK'ing" the PR, the author may need to present arguments and/or do research backing their suggested changes.
Squashing Commits
---------------------------
If your pull request is accepted for merging, you may be asked by a maintainer
to squash and or [rebase](https://git-scm.com/docs/git-rebase) your commits
### Squashing Commits
If your pull request contains fixup commits (commits that change the same line of code repeatedly) or too fine-grained
commits, you may be asked to [squash](https://git-scm.com/docs/git-rebase#_interactive_mode) your commits
before it will be merged. The basic squashing workflow is shown below.
git checkout your_branch_name
@ -149,6 +149,20 @@ the respective change set.
The length of time required for peer review is unpredictable and will vary from
pull request to pull request.
### Rebasing Changes
When a pull request conflicts with the target branch, you may be asked to rebase it on top of the current target branch.
The `git rebase` command will take care of rebuilding your commits on top of the new base.
This project aims to have a clean git history, where code changes are only made in non-merge commits. This simplifies
auditability because merge commits can be assumed to not contain arbitrary code changes. Merge commits should be signed,
and the resulting git tree hash must be deterministic and reproducible. The script in
[/contrib/verify-commits](/contrib/verify-commits) checks that.
After a rebase, reviewers are encouraged to sign off on the force push. This should be relatively straightforward with
the `git range-diff` tool explained in the [productivity
notes](/doc/productivity.md#diff-the-diffs-with-git-range-diff). To avoid needless review churn, maintainers will
generally merge pull requests that received the most review attention first.
Pull Request Philosophy
-----------------------