lkml.org 
[lkml]   [2010]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux-next: manual merge of the msm tree with the arm tree
From
Date
On Tue, 2010-10-19 at 19:34 +0100, Russell King wrote:
> On Tue, Oct 19, 2010 at 10:03:26AM -0700, Daniel Walker wrote:
> > On Tue, 2010-10-19 at 15:18 +0200, Arnd Bergmann wrote:
> > > On Tuesday 19 October 2010, Joe Perches wrote:
> > > > This could have been done:
> > > >
> > > > $ git show 08a610d9ef5394525b0328da0162d7b58c982cc4 | ./scripts/get_maintainer.pl --nogit | wc -l
> > > > 35
> > > >
> > > > Even then, using 35 CCs is generally silly.
> > > >
> > > > It might make some sense for a cover letter and a
> > > > patch series where the series made tree-wide changes
> > > > in multiple directories.
> > >
> > > Probably not even then: When a single mail header gets too long, you usually land
> > > in some spam filter and get hate mail from the list owners. The lkml limit is 1024
> > > characters (this may come from an official RFC, don't know), which is usually less
> > > than 35 recipients.
> >
> > Patches just shouldn't be this large.
>
> Patches get large. Sometimes they can't be sensibly broken up. We
> have to accept them as is sometimes. This is one of those occasions.
> See the example Nicolas gave you - it's no different.
>
> As for you saying that I'm the one getting excited about this - I'm not.
> I'm getting pissed off by how much discussion effort this trivial matter
> is taking and how much time it's wasting, which really isn't necessary.
> There's far better things to be done (such as testing) rather than taking
> hours to sort out what is basically a trivial merge issue.
>
> Now, you've said in your pull request:
>
> | Here is your pull request Russell. This has the patch which was part of
> | the conflict in MSM, "msm: allow uart to be conditionally disabled"..
> |
> | It's on top of v2.6.36-rc5, and it has one patch that is already in your
> | tree. It's "GIC: Dont disable INT in ack callback" .
> |
> | This pull request is exactly what I would send to Linus is the merge
> | window was open.
>
> As I'm merging it into a tree which does _not_ have the changes from
> Jeremy and Nicolas, what's this "the patch which was part of the
> conflict" and what's it going to do without Nicolas' changes?

Um , the patches I sent you are un-altered from what was originally in
my tree prior to the conflict.

I was just making note of the fact that a conflict in -next happened in
relation to that patch in my tree. I wasn't suggesting that my tree
changed at all.

> The point of dropping Jeremy and Nicolas' changes are to return to a
> state where things were before the troublesome change, so that the
> existing code works. Then Nicolas was going to take what is in my
> tree, and update the patches to take account of what's there.

yeah, that's what I'm assuming.. So I sent you exactly what I would have
sent Linus , i.e. doesn't take into account and troublesome patches of
any kind.

> If you're going to pre-empt that by fixing the stuff yourself, this
> whole exercise has been pointless, because it means that the code in
> your tree currently won't build without these other changes.

There's nothing fixed in my tree. I sent you a the pre-fixed tree. And
the troublesome patches will need to be conflict resolved even after my
tree is pulled.

> So at the moment I don't know whether or not I should pull your tree.

The tree should be what you wanted ..

Daniel



\
 
 \ /
  Last update: 2010-10-19 20:53    [W:0.084 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site