Re: git pull for update of netdev fails.

[Shawn Pearce <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 20 Sep 2006, Shawn Pearce wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Another, even more serious problems with rebasing: You can introduce a bug 
> > > by rebasing. Meaning: git-rebase can succeed, even compilation is fine, 
> > > but the sum of your patches, and the patches you are rebasing on, is 
> > > buggy. And there is _no_ way to bisect this, since the "good" version can 
> > > be gone for good.
> > 
> > True, however one would hope that you tested the commit before you
> > rebased it and found it to working.  And bisect should point at the
> > new version of that commit as the break.  And then you can debug
> > it there.
> 
> You misunderstood me. You can _introduce_ a bug by rebasing. _After_ 
> testing that everything is fine. You can even test the rebased branch and 
> miss the bug, since your original tests were more thorough.

Why were your original tests more thorough and your rebased testing
was less so?  Hmm?  Perhaps the test suite needs to be extended as
part of the rebased commit(s).

Of course a rebase-introduced bug could also be in the test suite,
such that you miss the true bug.  I've had bugs in the test suite
mask real bug, but never a bug both in the feature and in the test
due to a rebase or mad merge.  I guess I've just been lucky there.


When rebasing and even when doing a non-fast forward merge one
needs to keep in mind that your code is being edited on your behalf.
Not much different then if you open it in your favorite editor and
whack away at a keyboard for a while.  Sure these auto-edits work
most of the time, on their own and without user intervention, but
every once in while things get messed up.  Heck, I've seen editors
mess up source files such that they won't compile anymore.

So moral of the story is you probably should be testing even after
rebasing or cherry picking, and the testing shouldn't be any less
extensive than before you did the rebase/cherry-pick.  Which is one
reason why automated test suites can be useful, despite the risks
they also bring...

-- 
Shawn.