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
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 <[email protected]>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
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 <[email protected]>
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
On Mon, Oct 21, 2019 at 5:15 PM Jason Gunthorpe <[email protected]> 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 <[email protected]>
> 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
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 <[email protected]>
> > 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
On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <[email protected]> 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 <[email protected]>
> > > 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
On Mon, Oct 21, 2019 at 07:08:21PM +0200, Matteo Croce wrote:
> On Mon, Oct 21, 2019 at 7:01 PM Jason Gunthorpe <[email protected]> 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 <[email protected]>
> > > > 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
On Mon, 2019-10-21 at 17:11 +0000, 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 <[email protected]> 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 <[email protected]>
> > > > > 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.
On Mon, Oct 21, 2019 at 10:25:41AM -0700, Joe Perches wrote:
> On Mon, 2019-10-21 at 17:11 +0000, 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 <[email protected]> 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 <[email protected]>
> > > > > > 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
On Mon, 2019-10-21 at 17:39 +0000, 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