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

> 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).u

>
> * Split code movement and other stuff. For example extraction of
>    match_name_as_path() would be trivial if made in its own patch.
>
> I'd also make a separate patch "introduce the ref_list data-structure"
> to introduce struct ref_list and basic helper functions (constructors,
> mutators, destructors).
>
> It will take time and may appear to be counter-productive at first, but
> you'll get used to it, and you'll end up being actually more productive
> this way (well, maybe not "you" but the set "you + reviewers").
>