Karthik Nayak <karthik....@gmail.com> writes: > On 05/26/2015 09:19 PM, Matthieu Moy wrote: >> Seconded. Some reasons/guide to split: >> >> * Split trivial and non-trivial stuff. I can quickly review a >> "rename-only" patch even if it's a bit long (essentially, I'll check >> that you did find-and-replace properly), but reviewing a mix of >> renames and actual code change is hard. >> >> * Split controversial and non-controversial stuff. For example, you >> changed the ordering of fields in a struct. Perhaps it was not a good >> idea. Perhaps it was a good idea, but then you want this reordering to >> be alone in its patch so that you can explain why it's a good idea in >> the commit message (you'll see me use the word "why" a lot when >> talking about commit messages; not a coincidence). > > Since one of the patches is to restructure and rename 'for-each-ref', I > thought > It would be ideal to introduce the data structures within that patch, What do > you > think?
I don't have a universal answer: in general I prefer (let's say "this list prefers") splitting as much as possible. It may make sense to group "add data structure X" with "use data-structure X" to make sure that functions you introduce have a caller. What's clear is that your PATCH 1/2 is not split enough. Just go through it, you'll see code movement (a pain to review in patch format), straigthforward renamings (easy to review as-is, but disturbs the reviewer when mixed with something else) and actual new code. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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
