mbox

[GIT,PULL,1/3] ARM: mvebu: cleanup for v3.11 #4

Message ID 20130613212137.GE31667@titan.lakedaemon.net
State New
Headers show

Pull-request

git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4

Message

Jason Cooper June 13, 2013, 9:21 p.m. UTC
The following changes since commit c589f9b4b51317cfc530812fe90a9895bd51430e:

  arm: mvebu: mark functions of armada-370-xp.c as static (2013-05-21 13:44:32 +0000)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4

for you to fetch changes up to b15d0b5256056a67c5cb14c2d4d46dd12c8bfb99:

  bus: mvebu-mbus: Use pr_fmt (2013-06-08 14:10:19 +0000)

----------------------------------------------------------------
mvebu cleanup for v3.11 (round 4)

 - mvebu
    - use pr_fmt in mvebu-mbus driver

----------------------------------------------------------------
Ezequiel Garcia (1):
      bus: mvebu-mbus: Use pr_fmt

 drivers/bus/mvebu-mbus.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Comments

Olof Johansson June 14, 2013, 10:05 p.m. UTC | #1
On Thu, Jun 13, 2013 at 05:21:37PM -0400, Jason Cooper wrote:
> The following changes since commit c589f9b4b51317cfc530812fe90a9895bd51430e:
> 
>   arm: mvebu: mark functions of armada-370-xp.c as static (2013-05-21 13:44:32 +0000)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4

Pulled. I was this >< close to just cherry-picking the patch though, since
that's way more efficient for just a single patch. But that'd mess up your
downstream users.


-Olof
Olof Johansson June 14, 2013, 10:21 p.m. UTC | #2
On Thu, Jun 13, 2013 at 05:36:51PM -0400, Jason Cooper wrote:
> Arnd, Olof,
> 
> This branch is off by itself because it depends on mvebu/cleanup and
> mvebu/fixes-non-critical.  It's been in linux-next about a week and has
> an squirrelly merge conflict with armada-370-xp.c.  I've attached the
> resolution to the bottom of this email.
> 
> If you have any questions or if there is a better way for me to format
> this, please let me know.

Merged. Please check my conflict resolution once I push it out, but end delta
is similar.


-Olof
Jason Cooper June 15, 2013, 3:40 a.m. UTC | #3
On Fri, Jun 14, 2013 at 03:05:55PM -0700, Olof Johansson wrote:
> On Thu, Jun 13, 2013 at 05:21:37PM -0400, Jason Cooper wrote:
> > The following changes since commit c589f9b4b51317cfc530812fe90a9895bd51430e:
> > 
> >   arm: mvebu: mark functions of armada-370-xp.c as static (2013-05-21 13:44:32 +0000)
> > 
> > are available in the git repository at:
> > 
> >   git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4
> 
> Pulled. I was this >< close to just cherry-picking the patch though, since
> that's way more efficient for just a single patch. But that'd mess up your
> downstream users.

Thanks for not doing that.  I admit I hadn't considered this situation
when I put together this workflow.  Having mvebu stuff in linux-next
definitely prevents cherry-picking like above.

For the next window (things seems pretty calm in mvebu-land right now!)
I'll back off on the PRs for normal branches to avoid
commit/merge-tag/commit/merge-tag on your side.

Is there any other reason you might need to cherry-pick something in my
tree?  I can't think of one, and would prefer to keep doing linux-next
if possible.

thx,

Jason.
Jason Cooper June 15, 2013, 3:41 a.m. UTC | #4
On Fri, Jun 14, 2013 at 03:21:19PM -0700, Olof Johansson wrote:
> On Thu, Jun 13, 2013 at 05:36:51PM -0400, Jason Cooper wrote:
> > Arnd, Olof,
> > 
> > This branch is off by itself because it depends on mvebu/cleanup and
> > mvebu/fixes-non-critical.  It's been in linux-next about a week and has
> > an squirrelly merge conflict with armada-370-xp.c.  I've attached the
> > resolution to the bottom of this email.
> > 
> > If you have any questions or if there is a better way for me to format
> > this, please let me know.
> 
> Merged. Please check my conflict resolution once I push it out, but end delta
> is similar.

Found it at 5ae13ef4.  Looks good from here.  Thanks!

thx,

Jason.
Olof Johansson June 15, 2013, 5:18 a.m. UTC | #5
On Fri, Jun 14, 2013 at 8:40 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Fri, Jun 14, 2013 at 03:05:55PM -0700, Olof Johansson wrote:
>> On Thu, Jun 13, 2013 at 05:21:37PM -0400, Jason Cooper wrote:
>> > The following changes since commit c589f9b4b51317cfc530812fe90a9895bd51430e:
>> >
>> >   arm: mvebu: mark functions of armada-370-xp.c as static (2013-05-21 13:44:32 +0000)
>> >
>> > are available in the git repository at:
>> >
>> >   git://git.infradead.org/users/jcooper/linux.git tags/cleanup-3.11-4
>>
>> Pulled. I was this >< close to just cherry-picking the patch though, since
>> that's way more efficient for just a single patch. But that'd mess up your
>> downstream users.
>
> Thanks for not doing that.  I admit I hadn't considered this situation
> when I put together this workflow.  Having mvebu stuff in linux-next
> definitely prevents cherry-picking like above.
>
> For the next window (things seems pretty calm in mvebu-land right now!)
> I'll back off on the PRs for normal branches to avoid
> commit/merge-tag/commit/merge-tag on your side.
>
> Is there any other reason you might need to cherry-pick something in my
> tree?  I can't think of one, and would prefer to keep doing linux-next
> if possible.


Main reason for cherry-picking was just to save a few steps. I had
been doing git fetch / tig [for review] / git branch / git merge / git
merge / vi / git commit    for a few hours and was looking for ways to
avoid single-patch branch pulls.


But yeah, once you're in linux-next, it's game over. Which is the
downside of having your tree there. But there's upside to it too.


-Olof