| 15 | | * If you have multiple related changes, it is usually better to combine them all in one big patch, rather than attaching a long list of diffs. However, sometimes it may be useful to split the more controversial parts of the changes from those that can be applied without discussion. |
| 16 | | * Large changes should be split: |
| 17 | | * first required infrastructure changes in smaller parts |
| 18 | | * final work later (should be small as well, after infrastructure fixes are applied) |
| 19 | | * NOTE: These two points aren't opposites! Everything related should be joined (point 1), but idea is to extract independent sub-tasks from each large job (point 2). |
| | 14 | * If you have multiple related changes, it is usually better to combine them all in one big patch, rather than attaching a long list of diffs. However, sometimes it may be useful to split the more controversial parts of the changes from those that can be applied without discussion. This applies to very large patches as well: If there is a lot of technical rework required, then it can be a good idea to separate this from the interesting new code. This should make it easier to understand and discuss the important parts your patch. |
