On Tue, 12 May 2009 23:21:53 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Kim Phillips,
In message 20090512150139.a110609b.kim.phillips@freescale.com you wrote:
there seem to be recurring themes among these patches - this patchseries would be better grouped into theme based content instead of on a file by file basis. Eg., Removal of mpc512x.h shouldn't need 10 "prepare to remove" patches - it should be a single patch that removes all #include references, plus the file removal itself.
You are right, there should be just a single patch. But that patch would be big, and if it later turns out that I missed something
? wouldn't it be approximately the size of the file plus ten single-line hunks removing the #include lines in the rest of the code, i.e, a tad larger than patch 29/29? Plus it would significantly reduce the intimidating denominator number of this patchseries (making it approx. 10 commits less, and that's only on the subject of the removal of this mpc512x file).
during my testing, it will be a nightmare to debug.
Been there before. I already had such a patch stack, which I then collapsed into a small number of handy commits. Until it turned out that there was a nasty bug somewhere. And there is no "unsquash" option to "git-besect -i" yet ;-) In the end, I had to restore the previous version from backup tape.
I really thought about this, and I came to the conclusion that it's better to keep the commits separate, step by step.
I'm not going to tell you how to do your development, but you don't have to expose artefacts of your personal debugging cycles to reviewers nor unnecessarily clutter git bisect with unnecessary commits.
Kim