Skip to content

Update CONTRIBUTING.md for Grammar + Clarity #282

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

Merged
merged 2 commits into from
May 4, 2025
Merged
Changes from all commits
Commits
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
21 changes: 11 additions & 10 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,14 +31,15 @@ any contributed changes can be easily reproduced in future patches as more
changes are made.

Note that the `MAJOR.MINOR-patched` branch of that fork is maintained in the format
of a *patch tree*, which is a branch that has an entirely linear sequence of
of a *patch tree*, which is a branch that consists of an entirely linear sequence of
commits applied on top of another branch (in the case of the fork, `MAJOR.MINOR`),
each of which adding a new feature. Therefore, bug fixes to the patches applied
*will* be merged, but their changes gets squashed into the commit applying the
feature. Feature additions to the patch will be squashed into a single commit,
and then merged.

This also means that if another contributor on the fork gets a pull request merged
into the fork, you must *rebase*, not merge, your changes on top of the newly pulled
`MAJOR.MINOR-patched` branch, since the "history" of a patch tree branch might
change in a way that is incompatible with merge commits.
each of which adds a significant new feature. Therefore, a bug fix for an existing commit
in the patch tree *will* be merged when appropriate, but its changes will get combined
with that existing commit that adds the feature. A feature addition PR will be squashed
into a single, new commit, and then put on top of the patch tree.

This also means that if another contributor gets a pull request merged into
`MAJOR.MINOR-patched`, you must *rebase* your changes on top of the updated
`MAJOR.MINOR-patched` branch, as opposed to *merging* `MAJOR.MINOR-patched` into your
branch, since the "history" of a patch tree is likely to change in a way that is
incompatible with merge commits.