xfs
[Top] [All Lists]

Re: XFS Master Branch Rebase

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS Master Branch Rebase
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 28 Jul 2010 07:19:46 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Alex Elder <aelder@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20100728110954.GG655@dastard>
References: <1280247366.2002.111.camel@doink> <20100727232719.GR7362@dastard> <20100728084400.GA9516@xxxxxxxxxxxxx> <20100728110954.GG655@dastard>
User-agent: Mutt/1.5.20 (2009-08-17)
On Wed, Jul 28, 2010 at 09:09:54PM +1000, Dave Chinner wrote:
> If you call a single merge of 2.6.35-rc6 back into the for-2.6.36
> branch a "merge mess", then I'm guilty as charged.  However (and it
> is a *BIG* however),

It wasn't that simple.  We had a few unclean merges from mainline and
from for-linux to for-2.6.36 or similar branches.

> I haven't asked Alex to pull from that tree
> and upstream should not be pulling from downstream trees without a
> specific request to do so.
> 
> I'm maintaining that whole tree for _my_ benefit - I need a
> mainline-based tree that also contains all the non-mainline XFS
> commits, and I need to be able to update them independently.  Just
> because the tree contains a branch named "for-2.6.36" and has XFS
> commits that are not yet upstream doesn't mean the branch is a
> upstream pull target.

Yeah.  The normal way to maintain a development branch is to stay
is to never pull in mainline into an existing branch.  If we absolutely
need to update to a newer version from Linus' tree it should be rebased
ontop of it.  Unfortunately we'll need to do this once in a while
for something like XFS which has rather complex interactions with core
VM and VFS changes, so expecting the xfs development branch to be
a stable target is not generally a good idea.

<Prev in Thread] Current Thread [Next in Thread>