@@ -31,14 +31,15 @@ any contributed changes can be easily reproduced in future patches as more
31
31
changes are made.
32
32
33
33
Note 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
35
35
commits 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