* Pekka Enberg <penberg@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
