[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3a389360982c9d2730e6b29eb96523a562483ac.camel@perches.com>
Date: Mon, 21 Oct 2019 10:25:41 -0700
From: Joe Perches <joe@...ches.com>
To: Jason Gunthorpe <jgg@...lanox.com>,
Matteo Croce <mcroce@...hat.com>
Cc: Doug Ledford <dledford@...hat.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Potnuri Bharat Teja <bharat@...lsio.com>
Subject: Re: linux-next: Fixes tag needs some work in the rdma-fixes tree
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 <jgg@...lanox.com> 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 <mcroce@...hat.com>
> > > > > 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.
Powered by blists - more mailing lists