Subject: Re: linux-next: manual merge of the kmemcheck tree

From: Ingo Molnar <[email-masked]>
Date: Wed, 13 Aug 2008 14:05:07 +0200

* Pekka Enberg <[email-masked]> wrote:

> On Wed, 2008-08-13 at 13:52 +0200, Ingo Molnar wrote:
> > seems pretty sane to me. We use something quite similar in -tip, with 
> > the distinction that after a very short initial period [a few days at 
> > most] we try to keep development branches append-only as well.
> 
> Sure, I try to do that as well. But like I said, I've had a lot of 
> churn coming from the defrag patches recently...
> 
> But how do you deal with reverts, btw? Assuming you have a patch that 
> you've pushed out already but not asked Linus to pull, what do you do? 
> I currently use git-rebase -i and just drop the patch completely.

it depends - if the patch is the last one, i can just reset the topic 
back to just before that patch. If it's not, i use git-revert.

But the best way to deal with reverts is to use enough topic branches so 
that there's no 'mixing' between independent topics. Most reverts happen 
because there's some testing problem - so i do the revert in the 
_integration_ branch, not in the topic branch, and wait for the fix. 
Once the fix is available, it will be applied to the topic branch and 
the revert is dropped from the integration branch.

Worst-case i have to disable a full topic from the integration branch - 
but even in that case the topic commits still sit in the topic branch 
append-only and are waiting for the fix to arrive. One more detail: if a 
topic branch is broken i try not to merge upstream -rc's into that 
branch, to not artificially widen the window of breakage that could 
break bisection.

	Ingo