Message ID | 20130613212137.GE31667@titan.lakedaemon.net |
---|---|
State | New |
Headers | show |
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
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
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.
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.
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