Re: linux-next: manual merge of the msm tree with the arm tree

[Greg KH]

On Wed, Feb 02, 2011 at 08:00:31PM +0000, Russell King wrote:
> On Wed, Feb 02, 2011 at 11:43:59AM -0800, Greg KH wrote:
> > On Wed, Feb 02, 2011 at 10:29:14AM -0800, David Brown wrote:
> > > On Sun, Jan 30 2011, Stephen Rothwell wrote:
> > > 
> > > > Hi David,
> > > >
> > > > Today's linux-next merge of the msm tree got conflicts in
> > > > arch/arm/mach-msm/board-msm7x27.c, arch/arm/mach-msm/board-msm7x30.c,
> > > > arch/arm/mach-msm/board-qsd8x50.c and arch/arm/mach-msm/board-sapphire.c
> > > > between commit eda53d6d032effb653410b79e1b49e652a881744 ("ARM: P2V: avoid
> > > > initializers and assembly using PHYS_OFFSET") from the arm tree and
> > > > commit 07a3cc4814f790354d4c7be2c9dc6143a714a07a ("msm: Clean up useless
> > > > ifdefs") from the msm tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > What is the best way to resolve this?  I can't really merge against
> > > Russell's tree, since he may need to rebase his tree before the merge
> > > window?
> > 
> > Public trees should never be rebased, so that shouldn't happen.
> 
> No.  I refuse to operate in a rigid environment.
> 
> My tree is made available on the basis that the 'devel' branch is
> constantly remerged (sometimes many times a day) from the individual
> topic branches; 'devel' is a convenient branch for sfr to pull into
> linux-next, and for others to see what's in the tree.

merging is fine, right?

Not rebasing, you really don't want to do that.  Linus has been all over
that topic in the past, I doubt he wants to bring it up again in detail.

> I am not permitted by people in the community to keep my development
> work unpublished.
> 
> All the requirements from various different people are incompatible,
> so I've chosen a way which satisfies the majority on the ARM community,
> which is the community my tree serves.  It does not serve mainline
> community interests.

So the goal of the ARM community isn't for the mainline community?  That
sounds like a big problem.

> So I do not operate a "commit the patch and its fixed" policy except
> for branches which people need to be fixed; they need to discuss their
> requirements with me to achieve that.

I'm not telling you how to run your branches, other than the simple fact
of: "if it's public, it shouldn't be rebased".  See Linus's comments for
why this is.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/