Re: git pull for update of netdev fails.

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 20, 2006, 21:40 UTC
Message-ID: <20060920214001.GD24415@spearce.org>
In-Reply-To: <Pine.LNX.4.63.0609202325510.19042@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 17 quoted lines

> 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.