@@ -31,14 +31,15 @@ any contributed changes can be easily reproduced in future patches as more
3131changes are made.
3232
3333Note that the ` MAJOR.MINOR-patched ` branch of that fork is maintained in the format
34- of a * patch tree* , which is a branch that has an entirely linear sequence of
34+ of a * patch tree* , which is a branch that consists of an entirely linear sequence of
3535commits applied on top of another branch (in the case of the fork, ` MAJOR.MINOR ` ),
36- each of which adding a new feature. Therefore, bug fixes to the patches applied
37- * will* be merged, but their changes gets squashed into the commit applying the
38- feature. Feature additions to the patch will be squashed into a single commit,
39- and then merged.
40-
41- This also means that if another contributor on the fork gets a pull request merged
42- into the fork, you must * rebase* , not merge, your changes on top of the newly pulled
43- ` MAJOR.MINOR-patched ` branch, since the "history" of a patch tree branch might
44- change in a way that is incompatible with merge commits.
36+ each of which adds a significant new feature. Therefore, a bug fix for an existing commit
37+ in the patch tree * will* be merged when appropriate, but its changes will get combined
38+ with that existing commit that adds the feature. A feature addition PR will be squashed
39+ into a single, new commit, and then put on top of the patch tree.
40+
41+ This also means that if another contributor gets a pull request merged into
42+ ` MAJOR.MINOR-patched ` , you must * rebase* your changes on top of the updated
43+ ` MAJOR.MINOR-patched ` branch, as opposed to * merging* ` MAJOR.MINOR-patched ` into your
44+ branch, since the "history" of a patch tree is likely to change in a way that is
45+ incompatible with merge commits.
0 commit comments