public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte•hu>
To: Pekka Enberg <penberg@cs•helsinki.fi>
Cc: Stephen Rothwell <sfr@canb•auug.org.au>,
	Vegard Nossum <vegard.nossum@gmail•com>,
	linux-next@vger•kernel.org,
	Eduard - Gabriel Munteanu <eduard.munteanu@linux360•ro>,
	Christoph Lameter <cl@linux-foundation•org>
Subject: Re: linux-next: manual merge of the kmemcheck tree
Date: Wed, 13 Aug 2008 14:05:07 +0200	[thread overview]
Message-ID: <20080813120507.GA6631@elte.hu> (raw)
In-Reply-To: <1218628646.7813.324.camel@penberg-laptop>


* Pekka Enberg <penberg@cs•helsinki.fi> 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

  reply	other threads:[~2008-08-13 12:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-13  5:29 linux-next: manual merge of the kmemcheck tree Stephen Rothwell
2008-08-13  7:32 ` Ingo Molnar
2008-08-13  7:31   ` Pekka Enberg
2008-08-13  7:58     ` Ingo Molnar
2008-08-13  8:14       ` Pekka Enberg
2008-08-13  8:58         ` Ingo Molnar
2008-08-13 11:37           ` Pekka Enberg
2008-08-13 11:52             ` Ingo Molnar
2008-08-13 11:57               ` Pekka Enberg
2008-08-13 12:05                 ` Ingo Molnar [this message]
2008-08-13  7:41   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2008-12-30 12:18 Stephen Rothwell
2008-12-30 12:14 Stephen Rothwell
2008-10-28  5:14 Stephen Rothwell
2008-10-28  8:15 ` Ingo Molnar
2008-10-21  5:29 Stephen Rothwell
2008-10-21  7:32 ` Ingo Molnar
2008-10-21  8:07   ` Vegard Nossum
2008-10-21  8:28     ` Ingo Molnar
2008-10-21  5:15 Stephen Rothwell
2008-08-20  6:40 Stephen Rothwell
     [not found] <20080815164909.3d8beb10.sfr@canb.auug.org.au>
2008-08-15  7:04 ` Vegard Nossum
2008-08-15  8:00   ` Stephen Rothwell
2008-08-15  6:45 Stephen Rothwell
2008-08-15  6:43 ` Pekka Enberg
2008-08-15  8:17   ` Ingo Molnar
2008-08-13  5:26 Stephen Rothwell
2008-08-13  5:22 Stephen Rothwell
2008-07-28  4:09 Stephen Rothwell
2008-07-28  9:06 ` Ingo Molnar
2008-07-28 17:19   ` Stephen Rothwell
2008-07-28  4:01 Stephen Rothwell
2008-07-28  9:05 ` Ingo Molnar
2008-07-28  9:17   ` Vegard Nossum
2008-07-28  9:29     ` Ingo Molnar
2008-07-22  6:16 Stephen Rothwell
2008-07-22  6:52 ` Ingo Molnar
2008-07-22  8:18   ` Stephen Rothwell
2008-07-21  6:47 Stephen Rothwell
2008-07-11  6:32 Stephen Rothwell
2008-07-03  6:19 Stephen Rothwell
2008-07-03  6:12 Stephen Rothwell
2008-07-03  6:26 ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080813120507.GA6631@elte.hu \
    --to=mingo@elte$(echo .)hu \
    --cc=cl@linux-foundation$(echo .)org \
    --cc=eduard.munteanu@linux360$(echo .)ro \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=penberg@cs$(echo .)helsinki.fi \
    --cc=sfr@canb$(echo .)auug.org.au \
    --cc=vegard.nossum@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox