Message ID | cover.1608128666.git.matheus.bernardino@usp.br (mailing list archive) |
---|---|
Headers | show |
Series | Parallel Checkout (part I) | expand |
On Wed, Dec 16, 2020 at 3:50 PM Matheus Tavares <matheus.bernardino@usp.br> wrote: > > The previous rounds got many great suggestions about patches 1 to 10, > but not as many comments on the latter patches. Christian commented that > patches 10 and 11 are too long/complex, making the overall series harder > to review. So he suggested that I eject patches 10 to 19, and send them > later in a separated part. This will hopefully make the series easier to > review and move forward. (I also hope to include a desing doc in part 2 > to make those two bigger patches more digestible.) Thanks, and yeah, sorry I suggested that privately, but should have done it on the mailing list. I actually think that patches 10 and 11 (which each one contains 400+ new lines) in the previous series should be mostly alone in a part 2, with perhaps a part 3 that would have most of the rest, so improvements and tests. It might also be possible to split at least a bit a few things in patches 10 and 11. For example I think it's ok to add new configuration in a separate patch even if it's not used yet. It can just reserve the name. That could be in part 2 then. > Changes since v4: From a quick look at the range-diff, it looks good to me! Thanks, Christian.
Matheus Tavares <matheus.bernardino@usp.br> writes: > The previous rounds got many great suggestions about patches 1 to 10, > but not as many comments on the latter patches. Christian commented that > patches 10 and 11 are too long/complex, making the overall series harder > to review. So he suggested that I eject patches 10 to 19, and send them > later in a separated part. This will hopefully make the series easier to > review and move forward. (I also hope to include a desing doc in part 2 > to make those two bigger patches more digestible.) > > So this part is now composed only of the 9 preparatory patches, which > mainly focus on: (1) adding the 'struct conv_attrs' parameter to some > convert.c and entry.c functions (to avoid re-loading the attributes > during parallel checkout); and (2) making some functions public (for > parallel-checkout.c's later use). All of these patches look sensible to me. Will replace. Thanks.