Hi Tony, On Fri, 15 Apr 2016 08:41:40 -0700 Tony Lindgren <t...@atomide.com> wrote:
> * Boris Brezillon <boris.brezil...@free-electrons.com> [160415 04:52]: > > Roger, Tony, > > > > On Fri, 15 Apr 2016 13:54:34 +0300 > > Roger Quadros <rog...@ti.com> wrote: > > > > > On 15/04/16 13:09, Boris Brezillon wrote: > > > > Hi Roger, > > > > > > > > On Fri, 15 Apr 2016 12:34:04 +0300 > > > > Roger Quadros <rog...@ti.com> wrote: > > > > > > > >> Tony & Boris, > > > >> > > > >> On 14/04/16 00:25, Tony Lindgren wrote: > > > >>> * Roger Quadros <rog...@ti.com> [160407 03:10]: > > > >>>> Hi, > > > >>>> > > > >>>> As this series has cross dependency between omap and mtd subsystems, > > > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must > > > >>>> merge in together to avoid any conflicts/breakage during integration. > > > >>>> > > > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the > > > >>>> gpmc driver part and then I can provide the immutable branch. > > > >>> > > > >>> Looks good to me, please feel free to add: > > > >>> > > > >>> Acked-by: Tony Lindgren <t...@atomide.com> > > > >>> > > > >> > > > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the > > > >> below PULL request. > > > >> > > > >> Please take this into omap-soc and l2-mtd trees. Thanks. > > > > > > > > I Pulled this branch into nand/next and had to resolve a few conflicts > > > > (as you may have noticed, a few other reworks in the NAND and MTD layer > > > > have been merged in the meantime). > > > > > > OK. I'm not sure how well this will play when this merges into liunx-next > > > via the omap-soc tree. > > > > > > Instead, can you please create a non-mutable nand/base for me (which > > > could be > > > today's nand/next) and I can base my branch on that and Tony can use my > > > branch without causing any merge-conflict in linux-next? > > > > I just created a branch called nand/for-gpmc-rework based on today's > > nand/next, but I'm still unsure how to proceed once you've rebased your > > work on this branch? > > > > Tony will first have to pull my immutable branch, then pull yours, and > > then I'll have to pull an immutable branch from the the omap-soc tree > > to get your changes into my nand/next branch (in case other patches > > modify the same files before I send my PR). Am I missing something? > > If I'm not, then this option looks over-complicated to me. > > Well why don't you merge it all via NAND then? I'm not seeing > any merge conflicts with the arch/arm/mach-omap* code. I'm perfectly fine with that. Actually, that's what I first did (see the nand/next-with-gpmc-rework I asked Roger to validate). Roger, since you don't have any dependencies on omap stuff added after 4.6-rc1, I could even rebase your patches on top of nand/next to avoid this merge commit (and the associated conflict resolution). > > > ITOH, if we decide to let your patches go through the nand or omap-soc > > tree, only one immutable branch will be created, and either the nand or > > omap-soc maintainer (depending on who takes the patches) will have to > > pull it into its -next branch. > > > > I'm quite new to all this merging process, so don't hesitate to correct > > me if I'm wrong. > > Well the rules are that if something agreed to be immutable, then > it will never get redone. And the immutable branch should be based > on the absolute minimal set of patches against some earlier tag, > usually -rc1 is a good one. This avoids other tree to need to pull > in a huge amount of changes from other trees just to avoid merge > conflicts. How would you do it in this particular case. Say I have to provide you with an immutable branch, it should only contain Roger's patches, right? But this also means this immutable branch has to be pulled into my nand/next branch before all other changes touching the same set of files, which in turn means that I'll have to rebase and push -f my nand/next branch (which I'd like to avoid). Or should I just pull this immutable branch in my current nand/next and let you pull the same immutable branch in omap-soc. I mean, would this prevent conflicts when our branches are merged into linux-next, no matter the order. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
