Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, 2019-10-21 at 17:39 +, Jason Gunthorpe wrote: > Maybe output format and then parse it to check the min > length and verify the subject? I'm not too worried about that for now. 12 should still be good for quite awhile... $ git log --abbrev=1 --format='%h' --no-merges | \ awk '{print length($1);}' | sort -n | uniq -c 90 5 463746 6 320183 7 26244 8 1683 9 118 10 6 11
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 10:25:41AM -0700, Joe Perches wrote: > On Mon, 2019-10-21 at 17:11 +, Jason Gunthorpe wrote: > > On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote: > > > On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe wrote: > > > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote: > > > > > > I thought I saw that checkpatch was checking this now? > > > > > > > > > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > > > > > > Author: Matteo Croce > > > > > > Date: Wed Sep 25 16:46:38 2019 -0700 > > > > > > > > > > > > checkpatch.pl: warn on invalid commit id > > > > > > > > > > > > Maybe that check should also check that enough hash is provided and > > > > > > other details like the correct subject line? > > > > > > > > > > > > I also use a check that builds the fixes line from the commit id and > > > > > > requires it to be the same as the patch provided. This catches all > > > > > > sorts of wrong fixes lines, and sometimes git even recommends 13 > > > > > > chars > > > > > > :\ > > > > > > > > > > > > Jason > > > > > > > > > > Hi, > > > > > > > > > > actually I just call git_commit_info() which checks for validness. > > > > > I could also check that the hash is at least 12 digits, would be very > > > > > easy. > > > > > > > > IMHO you should do > > > > > > > > git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")' > > > > > > > > And check that the provided fixes line matches the above output > > > > exactly, or nearly exactly. People do lots of funny things to fixes > > > > lines.. > > > > > > > > > > The point in using git_commit_info() instead of calling git directly > > > is that the latter would generate an error if the working copy is not > > > a git tree (e.g. a tar.xz downloaded from kernel.org). > > > > Well, it does some checks and calls 'git log' so it seems like it > > could learn to call git log with different arguments, right? > > git commit SHA1's are not just 12 chars and could be any length. --abbrev forces a minimum bound to the kernel recommendation if the user has an old git or misconfigured git. git auto-detects if it needs more digits beyond 12. > And checkpatch already does use specific arguments > > my $output = `${git_command} log --no-color --format='%H %s' -1 $commit > 2>&1`; > > and then parses that $output. Maybe output format "%H %h %s" and then parse it to check the min length and verify the subject? Jason
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, 2019-10-21 at 17:11 +, Jason Gunthorpe wrote: > On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote: > > On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe wrote: > > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote: > > > > > I thought I saw that checkpatch was checking this now? > > > > > > > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > > > > > Author: Matteo Croce > > > > > Date: Wed Sep 25 16:46:38 2019 -0700 > > > > > > > > > > checkpatch.pl: warn on invalid commit id > > > > > > > > > > Maybe that check should also check that enough hash is provided and > > > > > other details like the correct subject line? > > > > > > > > > > I also use a check that builds the fixes line from the commit id and > > > > > requires it to be the same as the patch provided. This catches all > > > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars > > > > > :\ > > > > > > > > > > Jason > > > > > > > > Hi, > > > > > > > > actually I just call git_commit_info() which checks for validness. > > > > I could also check that the hash is at least 12 digits, would be very > > > > easy. > > > > > > IMHO you should do > > > > > > git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")' > > > > > > And check that the provided fixes line matches the above output > > > exactly, or nearly exactly. People do lots of funny things to fixes > > > lines.. > > > > > > > The point in using git_commit_info() instead of calling git directly > > is that the latter would generate an error if the working copy is not > > a git tree (e.g. a tar.xz downloaded from kernel.org). > > Well, it does some checks and calls 'git log' so it seems like it > could learn to call git log with different arguments, right? git commit SHA1's are not just 12 chars and could be any length. And checkpatch already does use specific arguments my $output = `${git_command} log --no-color --format='%H %s' -1 $commit 2>&1`; and then parses that $output.
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote: > On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe wrote: > > > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote: > > > > I thought I saw that checkpatch was checking this now? > > > > > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > > > > Author: Matteo Croce > > > > Date: Wed Sep 25 16:46:38 2019 -0700 > > > > > > > > checkpatch.pl: warn on invalid commit id > > > > > > > > Maybe that check should also check that enough hash is provided and > > > > other details like the correct subject line? > > > > > > > > I also use a check that builds the fixes line from the commit id and > > > > requires it to be the same as the patch provided. This catches all > > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars > > > > :\ > > > > > > > > Jason > > > > > > Hi, > > > > > > actually I just call git_commit_info() which checks for validness. > > > I could also check that the hash is at least 12 digits, would be very > > > easy. > > > > IMHO you should do > > > > git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")' > > > > And check that the provided fixes line matches the above output > > exactly, or nearly exactly. People do lots of funny things to fixes > > lines.. > > > > The point in using git_commit_info() instead of calling git directly > is that the latter would generate an error if the working copy is not > a git tree (e.g. a tar.xz downloaded from kernel.org). Well, it does some checks and calls 'git log' so it seems like it could learn to call git log with different arguments, right? Jason
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe wrote: > > On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote: > > > I thought I saw that checkpatch was checking this now? > > > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > > > Author: Matteo Croce > > > Date: Wed Sep 25 16:46:38 2019 -0700 > > > > > > checkpatch.pl: warn on invalid commit id > > > > > > Maybe that check should also check that enough hash is provided and > > > other details like the correct subject line? > > > > > > I also use a check that builds the fixes line from the commit id and > > > requires it to be the same as the patch provided. This catches all > > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars > > > :\ > > > > > > Jason > > > > Hi, > > > > actually I just call git_commit_info() which checks for validness. > > I could also check that the hash is at least 12 digits, would be very easy. > > IMHO you should do > > git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")' > > And check that the provided fixes line matches the above output > exactly, or nearly exactly. People do lots of funny things to fixes > lines.. > The point in using git_commit_info() instead of calling git directly is that the latter would generate an error if the working copy is not a git tree (e.g. a tar.xz downloaded from kernel.org). -- Matteo Croce per aspera ad upstream
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 05:39:06PM +0200, Matteo Croce wrote: > > I thought I saw that checkpatch was checking this now? > > > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > > Author: Matteo Croce > > Date: Wed Sep 25 16:46:38 2019 -0700 > > > > checkpatch.pl: warn on invalid commit id > > > > Maybe that check should also check that enough hash is provided and > > other details like the correct subject line? > > > > I also use a check that builds the fixes line from the commit id and > > requires it to be the same as the patch provided. This catches all > > sorts of wrong fixes lines, and sometimes git even recommends 13 chars > > :\ > > > > Jason > > Hi, > > actually I just call git_commit_info() which checks for validness. > I could also check that the hash is at least 12 digits, would be very easy. IMHO you should do git log --abbrev=12 -1 --format='Fixes: %h (\"%s\")' And check that the provided fixes line matches the above output exactly, or nearly exactly. People do lots of funny things to fixes lines.. Jason
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 5:15 PM Jason Gunthorpe wrote: > > On Mon, Oct 21, 2019 at 10:50:33AM -0400, Doug Ledford wrote: > > On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote: > > > Hi all, > > > > > > In commit > > > > > > 612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept") > > > > > > Fixes tag > > > > > > Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and > > > ISS for iWARP connections") > > > > > > has these problem(s): > > > > > > - SHA1 should be at least 12 digits long > > > Can be fixed by setting core.abbrev to 12 (or more) or (for git > > > v2.11 > > > or later) just making sure it is not set (or set to "auto"). > > > > I'll leave it to Potnuri to fix his stuff. As for the rdma tree, the 10 > > digit hash is still unique as of today, so I won't rebase the official > > branch to fix this. However, I'll see about adding a check for this in > > my workflow. Thanks. > > I thought I saw that checkpatch was checking this now? > > commit a8dd86bf746256fbf68f82bc13356244c5ad8efa > Author: Matteo Croce > Date: Wed Sep 25 16:46:38 2019 -0700 > > checkpatch.pl: warn on invalid commit id > > Maybe that check should also check that enough hash is provided and > other details like the correct subject line? > > I also use a check that builds the fixes line from the commit id and > requires it to be the same as the patch provided. This catches all > sorts of wrong fixes lines, and sometimes git even recommends 13 chars > :\ > > Jason Hi, actually I just call git_commit_info() which checks for validness. I could also check that the hash is at least 12 digits, would be very easy. Joe? -- Matteo Croce per aspera ad upstream
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, Oct 21, 2019 at 10:50:33AM -0400, Doug Ledford wrote: > On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote: > > Hi all, > > > > In commit > > > > 612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept") > > > > Fixes tag > > > > Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and > > ISS for iWARP connections") > > > > has these problem(s): > > > > - SHA1 should be at least 12 digits long > > Can be fixed by setting core.abbrev to 12 (or more) or (for git > > v2.11 > > or later) just making sure it is not set (or set to "auto"). > > I'll leave it to Potnuri to fix his stuff. As for the rdma tree, the 10 > digit hash is still unique as of today, so I won't rebase the official > branch to fix this. However, I'll see about adding a check for this in > my workflow. Thanks. I thought I saw that checkpatch was checking this now? commit a8dd86bf746256fbf68f82bc13356244c5ad8efa Author: Matteo Croce Date: Wed Sep 25 16:46:38 2019 -0700 checkpatch.pl: warn on invalid commit id Maybe that check should also check that enough hash is provided and other details like the correct subject line? I also use a check that builds the fixes line from the commit id and requires it to be the same as the patch provided. This catches all sorts of wrong fixes lines, and sometimes git even recommends 13 chars :\ Jason
Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
On Mon, 2019-10-21 at 18:41 +1100, Stephen Rothwell wrote: > Hi all, > > In commit > > 612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept") > > Fixes tag > > Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and > ISS for iWARP connections") > > has these problem(s): > > - SHA1 should be at least 12 digits long > Can be fixed by setting core.abbrev to 12 (or more) or (for git > v2.11 > or later) just making sure it is not set (or set to "auto"). I'll leave it to Potnuri to fix his stuff. As for the rdma tree, the 10 digit hash is still unique as of today, so I won't rebase the official branch to fix this. However, I'll see about adding a check for this in my workflow. Thanks. -- Doug Ledford GPG KeyID: B826A3330E572FDD Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
linux-next: Fixes tag needs some work in the rdma-fixes tree
Hi all, In commit 612e0486ad08 ("iw_cxgb4: fix ECN check on the passive accept") Fixes tag Fixes: 92e7ae7172 ("iw_cxgb4: Choose appropriate hw mtu index and ISS for iWARP connections") has these problem(s): - SHA1 should be at least 12 digits long Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11 or later) just making sure it is not set (or set to "auto"). -- Cheers, Stephen Rothwell pgp3xN3HXn9eC.pgp Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the rdma-fixes tree
Hi all, In commit 5efda3b6b122 ("IB/mlx5: Fix scatter to CQE in DCT QP creation") Fixes tag Fixes: 5d6ff1babe ("IB/mlx5: Support scatter to CQE for DC transport type") has these problem(s): - SHA1 should be at least 12 digits long Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11 or later) just making sure it is not set (or set to "auto"). -- Cheers, Stephen Rothwell pgpGQWfRmHVqW.pgp Description: OpenPGP digital signature