Lines Matching full:changes

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