On Mon, Feb 25, 2019 at 09:46:56AM -0800, Nick Desaulniers wrote:
> On Mon, Feb 25, 2019 at 9:35 AM Nathan Chancellor
> <natechancellor@xxxxxxxxx> wrote:
> >
> > On Mon, Feb 25, 2019 at 03:47:19PM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Feb 25, 2019 at 03:45:13PM +0100, Greg Kroah-Hartman wrote:
> > > > On Sun, Feb 24, 2019 at 11:13:01PM -0700, Nathan Chancellor wrote:
> > > > > Hi Greg and Sasha,
> > > > >
> > > > > Attached are three mbox files containing patches that bring the Clang
> > > > > backports that Nick did in 4.9.139 up to date with what is currently in
> > > > > 4.14 and mainline, as well as fix warnings that are present in the arm64
> > > > > and x86_64 defconfigs here and in AOSP (cuttlefish_defconfig). All of
> > > > > these warnings are fixed in 4.14 so there will be no regressions from
> > > > > upgrading.
> > > >
> > > > Really? I see a number of these only showing up in much newer kernels.
> >
> > Sigh that's what I get for not double checking my email after adding
> > patches :(
> >
> > > > Specifically these patches:
> > > > 1f60652dd586 ("pinctrl: max77620: Use define directive for max77620_pinconf_param values")
> > > > a0dd6773038f ("phy: tegra: remove redundant self assignment of 'map'")
> > > > a9903f04e0a4 ("sched/sysctl: Fix attributes of some extern declarations")
> > > >
> > > > from the "arm" mbox you provided. Why shouldn't the above patches go
> > > > into 4.14.y and in some cases, also 4.19.y and 4.20.y?
> >
> > They should. All three pick cleanly to 4.14.y. Only the first one needs
> > to be taken into 4.19.y and 4.20.y.
>
> I feel like I need a script that given a sha, tells me what LTS
> branches the patch is in or not. I have this to tell me "when (what's
> the first tag that contains this commit)" a patch first landed:
>
> function first_tag () {
> tag=$1
> git describe --contains "$tag" | sed 's/~.*//'
> }
>
> So say a patch landed in 4.15-rc1; and I want to backport to 4.9 and
> 4.14 (but it's already been backported to 4.14). Does anyone have a
> script to check this quickly? The process for seeing which LTS
> contains a commit or not still is very manual. I guess backports that
> require modification probably complicate the search further. Just
> asking, in case this is already a solved problem.
Here's the script that I use that does just that:
https://github.com/gregkh/gregkh-linux/blob/master/scripts/fix_in_what_release
It requires 3 things:
- a directory of all kernel logs to search quickly to avoid 'git
log'. I use the ones I keep at: https://github.com/gregkh/kernel-history/tree/master/logs
- the stable queue git repo, to be able to search the stable
kernel trees quickly.
- the latest git tree from Linus, to fall back to if the commit
isn't in any of the above places.
Hope that helps.
greg k-h
