Michel Dänzer <mic...@daenzer.net> writes: > This does mean though that if one has only up to patch 3 applied (e.g. > during a bisection), one is exposed to the issues fixed by patch 4. So > maybe patch 4 should be squashed into patch 3.
That's a very important point -- developing code in small logical steps
is a most excellent plan, but the resulting set of commits in git need
to satisfy different requirements:
1) Make forward progress; no commit should regress any functionality,
no commit should introduce compiler warnings (or, even worse,
compiler errors). Adam Jackson has reminded me several times to use
'git rebase -x make' to check a long sequence of patches with the
compiler. Sometimes I remember on my own.
2) Each patch should be a single change, self contained and easy to
understand. If you can't summarize the patch in one line, it's
probably too complicated for anyone to review effectively. If you
ever use the word 'and' in the summary line, that's a good sign that
the patch does more than one thing and should be split apart.
3) The series should tell a good story. Just like writing a book, the
final product (sequence of patches or storyline) almost certainly
will not be presented in the original development
order. Splitting/merging patch chunks and reordering commits is
almost always necessary in a long patch series.
I think review takes time related to some high order polynomial function
of the patch length; maybe just quadratic, but possibly more. Long
patches that are purely mechanical changes (replacing function names,
cleaning up whitespace) might be an exception to this rule. Remember
that development is a shared activity, and that spending time making the
patches easy to review moves work from reviewer to committer, and that
is almost always a net win in total development time.
--
-keith
signature.asc
Description: PGP signature
_______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
