Lines Matching refs:changes

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