[U-Boot] [PATCH 00/29] Rework MPC512x Support

[Kim Phillips]

On Tue, 12 May 2009 23:21:53 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Kim Phillips,
> 
> In message <20090512150139.a110609b.kim.phillips at 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