On Tue, Mar 23, 2021 at 01:28:38PM -0700, Nick Desaulniers wrote: > On Tue, Mar 23, 2021 at 12:05 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > The only time git gets involved is when we do a -rc release or when we > > do a "real" release, and then we use 'git quiltimport' on the whole > > stack. > > > > Here's a script that I use (much too slow, I know), for checking this > > type of thing and I try to remember to run it before every cycle of -rc > > releases: > > https://github.com/gregkh/commit_tree/blob/master/find_fixes_in_queue > > > > It's a hack, and picks up more things than is really needed, but I would > > rather it error on that side than the other. > > Yes, my script is similar. Looks like yours also runs on a git tree. > > I noticed that id_fixed_in runs `git grep -l --threads=3 <sha>` to > find fixes; that's neat, I didn't know about `--threads=`. I tried it > with ae46578b963f manually: > > $ git grep -l --threads=3 ae46578b963f > $ > > Should it have found a7889c6320b9 and 773e0c402534? Perhaps `git log > --grep=<sha>` should be used instead? I thought `git grep` only greps > files in the archive, not commit history? Yes, it does only grep the files in the archive. But look closer at the archive that this script lives in :) This archive is a "blown up" copy of the Linux kernel tree, with one file per commit. The name of the file is the commit id, and the content of the file is the changelog of the commit itself. So it's a hack that I use to be able to simply search the changelogs of all commits to find out if they have a "Fixes:" tag with a specific commit id in it. So in your example above, in the repo I run it and get: ~/linux/stable/commit_tree $ git grep -l --threads=3 ae46578b963f changes/5.2/773e0c40253443e0ce5491cb0e414b62f7cc45ed ids/5.2 Which shows me that in commit 773e0c402534 ("afs: Fix afs_xattr_get_yfs() to not try freeing an error value") in the kernel tree, it has a "Fixes:" tag that references "ae46578b963f". It also shows me that commit ae46578b963f was contained in the 5.2 kernel release, as I use the "ids/" subdirectory here for other fast lookups (it's a tiny bit faster than 'git describe --contains'). I don't know how your script is walking through all possible commits to see if they are fixing a specific one, maybe I should look and see if it's doing it better than my "git tree/directory as a database hack" does :) thanks, greg k-h
