Lines Matching full:changes
77 resolving conflicts and dealing with API changes.
79 Only the most simple changes should be formatted as a single patch;
80 everything else should be made as a logical series of changes. Splitting
86 changes found in your working revision control system. Instead, the
87 changes you have made need to be considered in their final form, then
89 discrete, self-contained changes, not the path you took to get to those
90 changes.
93 patch. These changes can be small ("add a field to this structure") or
100 changes in the same patch. If a single patch fixes a critical security
181 support other changes coming in later patch, say so. If internal APIs are
182 changed, detail those changes and how other developers should respond. In
191 option to diff will associate function names with changes, making the
194 You should avoid including changes to irrelevant files (those generated by
285 which have had gratuitous white-space changes or line wrapping performed