[lkml]   [2006]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][RFC] exception processing in early boot
On Wed, Aug 30, 2006 at 10:00:15AM -0400, Sean wrote:
> On Wed, 30 Aug 2006 15:16:12 +0200
> Willy Tarreau <> wrote:
> > That's already what I'm doing, and yes, it is *that* hard. We're literally
> > speaking about *thousands* of patches. It's as difficult to find one patch
> > within 2.6 git changes as it is to find a useful mail in the middle of 99%
> > spam. This is not because of GIT but because of the number of changes.
> Willy,
> The git-cherry command might be useful for you in this situation. It will
> show you all the patches in one branch that have been merged in an upstream
> branch, and those that haven't. Not sure if it's perfect for your situation,
> but may be worth a look.

I've already used it (it's what I was using when to maintain the 2.4-hf
tree in parallel to Marcelo's mainline). But it's useful when you have
*a few* patches. I'm really speaking about *thousands* of patches that
get merged into 2.6 every few months and this is what makes the job difficult.
Not to mention that they also get merged in 2.6-mm in advance, or that
sometimes they are obsoleted and/or replaced by something else.

Clearly, I'm not going to track all 2.6 patch by patch to maintain 2.4 !

The most scalable workflow is distributed, and should be oriented towards
push and not pull. We just have to ensure that *someone* takes care of
each patch and tracks it up to its merge.

> Sean


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-08-30 16:13    [W:0.032 / U:4.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site