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

[Daniel Walker]

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

--
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/