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).u
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?
* 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").
Thanks for this.
--
Regards,
Karthik
--
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