Re: [PATCH v2 1/2] for-each-ref: re-structure code for moving to 'ref-filter'

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Karthik Nayak <karthik.188@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/