All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jon Medhurst <tixy@yxit.co.uk>
Subject: Re: linux-next: manual merge of the moduleh tree with the arm tree
Date: Thu, 25 Aug 2011 18:40:54 -0400	[thread overview]
Message-ID: <4E56CF76.70201@windriver.com> (raw)
In-Reply-To: <20110825163901.GA467@flint.arm.linux.org.uk>

On 11-08-25 12:39 PM, Russell King wrote:
> On Thu, Aug 25, 2011 at 12:33:51PM -0400, Paul Gortmaker wrote:
>> On 11-08-25 01:17 AM, Stephen Rothwell wrote:
>>> Hi Paul,
>>>
>>> Today's linux-next merge of the moduleh tree got a conflict in
>>> arch/arm/mach-bcmring/mm.c between commit 2d5e975b2194 ("ARM:
>>> mach-bcmring: Setup consistent dma size at boot time") from the arm tree
>>> and commit 9bc7d81e271e ("arm: fix implicit use of page.h in
>>> mach-bcmring/mach-jornada") from the moduleh tree.
>>
>> I can't really relocate the page.h inclusion in a trivial way to
>> make this conflict go away.  But since the implicit header use fixes
>> for arm are independent and don't actually depend on anything in the
>> rest of the module.h tree, I can set about to giving these to Russell
>> for his arm-next branch anytime.  I'll do that shortly.
> 
> For such a trivial conflict, I don't think we need to do anything.  Linus
> has said publically that he likes to sort out conflicts as it allows him
> to have a wider knowledge of what's going on in the kernel tree.
> 
> So, given that the fixup is soo obvious, I don't think we need to play
> games redistributing patches - we just need to be aware of the conflict
> and mention it to Linus when we merge.

OK.  I was entertaining feeding some of the really obvious and simple
parts of the moduleh branch out to the various maintainers just to
reduce its overall size, but in the end I guess that just makes work
for me and them -- vs. a single pull request to Linus for addition to
v3.2-rc1.   I'll just stay the course and Stephen will have to rerere
the merge conflict resolution for a while -- something I'm certain
that he has automated long long ago.

Thanks,
Paul.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	<linux-next@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Jon Medhurst <tixy@yxit.co.uk>
Subject: Re: linux-next: manual merge of the moduleh tree with the arm tree
Date: Thu, 25 Aug 2011 18:40:54 -0400	[thread overview]
Message-ID: <4E56CF76.70201@windriver.com> (raw)
In-Reply-To: <20110825163901.GA467@flint.arm.linux.org.uk>

On 11-08-25 12:39 PM, Russell King wrote:
> On Thu, Aug 25, 2011 at 12:33:51PM -0400, Paul Gortmaker wrote:
>> On 11-08-25 01:17 AM, Stephen Rothwell wrote:
>>> Hi Paul,
>>>
>>> Today's linux-next merge of the moduleh tree got a conflict in
>>> arch/arm/mach-bcmring/mm.c between commit 2d5e975b2194 ("ARM:
>>> mach-bcmring: Setup consistent dma size at boot time") from the arm tree
>>> and commit 9bc7d81e271e ("arm: fix implicit use of page.h in
>>> mach-bcmring/mach-jornada") from the moduleh tree.
>>
>> I can't really relocate the page.h inclusion in a trivial way to
>> make this conflict go away.  But since the implicit header use fixes
>> for arm are independent and don't actually depend on anything in the
>> rest of the module.h tree, I can set about to giving these to Russell
>> for his arm-next branch anytime.  I'll do that shortly.
> 
> For such a trivial conflict, I don't think we need to do anything.  Linus
> has said publically that he likes to sort out conflicts as it allows him
> to have a wider knowledge of what's going on in the kernel tree.
> 
> So, given that the fixup is soo obvious, I don't think we need to play
> games redistributing patches - we just need to be aware of the conflict
> and mention it to Linus when we merge.

OK.  I was entertaining feeding some of the really obvious and simple
parts of the moduleh branch out to the various maintainers just to
reduce its overall size, but in the end I guess that just makes work
for me and them -- vs. a single pull request to Linus for addition to
v3.2-rc1.   I'll just stay the course and Stephen will have to rerere
the merge conflict resolution for a while -- something I'm certain
that he has automated long long ago.

Thanks,
Paul.

  reply	other threads:[~2011-08-25 22:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25  5:17 linux-next: manual merge of the moduleh tree with the arm tree Stephen Rothwell
2011-08-25 16:33 ` Paul Gortmaker
2011-08-25 16:33   ` Paul Gortmaker
2011-08-25 16:39   ` Russell King
2011-08-25 22:40     ` Paul Gortmaker [this message]
2011-08-25 22:40       ` Paul Gortmaker
2011-08-25 23:11       ` Stephen Rothwell
2011-08-25 23:11         ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2011-08-11  5:02 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E56CF76.70201@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=sfr@canb.auug.org.au \
    --cc=tixy@yxit.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.