[PATCHv13 00/40] ARM: TI SoC clock DT conversion

[Tony Lindgren]

* Mike Turquette <mturquette at linaro.org> [140115 11:25]:
> Quoting Tony Lindgren (2014-01-15 09:13:23)
> > * Mike Turquette <mturquette at linaro.org> [140114 19:52]:
> > > > 
> > > > These 40 patches apply very cleanly on top of clk-next with 2
> > > > exceptions:
> > > > 
> > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
> > > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
> > > > on 3.13-rc1).
> > > > 
> > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
> > > > resolved correctly but would like verification.
> > > > 
> > > > I'd prefer to simply merge these patches into clk-next, which is the
> > > > most straightforward route. Any ideas on how to handle the missing
> > > > AM35xx dtsi data? It can always go as a separate fix after this stuff
> > > > gets merged which, ironically, is how that file was created in the first
> > > > place.
> > 
> > You could do something like this to take advantage of fast forward and
> > not have to do a merge back from mainline:
> > 
> > $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
> > $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
> > $ git am am3517-clk-patch
> > $ git checkout clk-next
> > $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc
> 
> That makes sense, but is there anything bad about doing that for a
> branch you intend to send as a pull request? I don't see how any of the
> commits get re-written or anything... I just wonder if there is some
> subtlety that I am not accounting for that makes this approach bad for
> sending to Linus.

No there should not be any issues. That's the preferred way to keep
development branches updated and pullable in long term without any need
to rebase.

Note that there will be only a merge commit if there is a conflict,
otherwise the fast forward will be transparent. So the trick to avoiding
rebasing and back merges is to apply patches against what they need in a
local branch, then after testing merge that local branch into the development
branch. Then for the upsteam pull request, you just need to make it against
the -rc you merged in.

AFAIK what Linus does not like is doing a back merge to a development
branch from mainline, probably as it adds a pointless commit. Or rebasing
a branch as that way it won't stay pullable.

Regards,

Tony