From: Junio C Hamano <gits...@pobox.com> > > Antoine Pelisse <apeli...@gmail.com> writes: > >> I'm not exactly sure I understand the point of not squashing all those >> patches together ? >> It's not like one is going without the others, or that the commit >> message provides some new information (except for the name of the >> file, but that is not very relevant either). The downside is that it's >> _many_ messages to bypass when reading mails from small-screen devices >> :-) > > The only plausible reason I could think of is to avoid clashing with > topics in-flight, but then the approach to produce per-file patch is > not perfect for that purpose, either, when more than one topic in > flight touch the same file at different places. > > I'd say probably the best organization would be something like: > > * A set of clean-up patches to normalize oddball usages of existing > functions (e.g. normalize 'prefixcmp(a,b) != 0' in some file(s) > to 'prefixcmp(a,b)'); > > * A single patch to introduce the new function(s), to be applied on > top of 1.8.5; > > * A large patch to convert all uses of prefixcmp to starts_with and > suffixcmp to ends_with in the 1.8.5 codebase; > > * A patch for each topic in flight to convert newly introduced > prefixcmp/suffixcmp to starts_with/ends_with, to be applied after > the topic graduates to 'master' after 1.8.5; and then finally > > * A separate patch to remove prefixcmp and suffixcmp, to be applied > after _all_ in-flight topic has graduated to 'master'.
Ok, I will wait for 1.8.5 and then send a patch series like what you suggest. Thanks, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
