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@xxxxxxxxxxxx> 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@xxxxxxxxxx> > > > > 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
