> IIRC from previous discussions, kernel.org's main performance problem is > I/O, not CPU. Are there any provisions for sharing rev-caches between > similar repositories, as we already do for objects? I haven't implemented a transmission protocol or anything, but it would be perfectly possible to copy cache slices from one repo to another. Generating the revision cache from scratch on large repos can take several minutes, so this wouldn't be a bad idea. > That depends primarily on how heavily the patches needed to change in > response to review comments, but until the series lands in 'next', you > would typically send updated series as a replacement, not incremental. > > Many people seemed to be interested in the series and had a volume of > comments on it. I suspect the updated series would be quite different > from the original, so for the next round I would suspect it would be best > to start anew, marking them as [PATCH N/M (v2)], in a fresh thread. It > would help reviewers if you said "this corresponds to [PATCH 3/5] in the > original series, with the following improvements based on X and Y's > comments" after the three-dash line. Ok, that sounds good. I've added a new patch as well so the numbering changes. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html