Lines Matching refs:changes
86 Split up longer patches into a patch series of logical code changes.
108 semantic changes (or even function renames) are done in a separate patch
119 the original file as separating hunks of changes.
126 to focus on the few changes that weren't wholesale code motion.
130 Don't include irrelevant changes
134 changes to bits of code that would otherwise not be touched by the
138 as a separate patch which makes no semantic changes; don't put it in the
150 historical record of why the changes you applied were necessary or
208 changes might have an unintended effect on other areas of the code you
213 your patches - either to ensure that future changes won't regress your
362 may object to early changes that don't make sense until the end of the
368 Make sure your cover letter includes a diffstat of changes made over the
384 - the patch depends on some pending kernel changes which haven't yet
426 proactively respond to suggestions with changes or justifications for
442 if you don't do it then your changes will never get into QEMU.
505 For later versions of patches, include a summary of changes from
514 patch email, and this is where the "changes since previous version"
539 commit message, as well as listing the changes from the previous
541 changes.