(+cc: Elijah, who has more experience in this subject than I do)
Hi,
Michael Haggerty wrote:
> My renovation of refs.c [1] is currently at 66 patches and counting.
> What can I say?: (1) I like to make changes in the smallest irreducible
> steps and (2) there is a lot that needed to be done in refs.c.
>
> When I'm done
We've seen series with fifty-something patches on this list before.
My (generic) advice:
1. Send in installments, early and often. It would not be fun if the
first ten patches have a fatal flaw that means the later ones have
to be reworked.
2. Make sure the cover letter makes people want to read the later
patches. Make sure each patch has a commit message that motivates
it alone or explains how it fits into the larger picture.
3. When a patch is not intended to cause any functional change, say
so, so reviewers can check that.
4. Include test scripts declaring what effect (or lack thereof) each
patch is supposed to have.
5. "Smallest irreducible step" is not necessarily the appropriate
granularity when publishing. "Largest piece that a person would
want to review, apply, or revert independently" is.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html