Re: Mistakes in commit log messages

[Alan Mackenzie <acm@muc.de>]

Hello, Jim.

On Tue, Apr 11, 2023 at 11:31:55 -0700, Jim Porter wrote:
> On 4/11/2023 7:01 AM, Alan Mackenzie wrote:
> >   
> > +  /^\* [a-zA-Z0-9_.~#-]/ {
> > +    nfiles++
> > +    if ((rc = (getline x < $2)) < 0) {
> > +      status = 1
> > +      print "File " $2 " cannot be read: [" ERRNO "]"
> > +    }
> > +    close($2)
> > +  }

> One thing to be careful of here (which is why I did the 'match'/'substr' 
> dance in my patch) is that we need to be able to handle lines like this 
> correctly:

>    * some/file.el: New file.

Yes, you're right, thanks.  These little things are always tripping me
up.

[ .... ]

> Also, using 'getline' will work for checking files, but not directories. 
> I'm not sure this ever comes up in practice, but it might occur once in 
> a while if we import a large package into the Emacs tree. We could do a 
> bit of feature-checking and upgrade to using 'stat' if we have a newish 
> gawk. That way, gawk users would get proper checks for this (rare) case. 
> (This might not be strictly necessary.)

This, too.

> Finally, I think it would make sense to have this be a purely advisory 
> warning for now so that we could check it into the Emacs tree soon-ish. 
> As Eli suggests, we can try running with this hook locally, but since 
> I've already added some Lisp code to generate the changelog for my 
> workflow, I'm probably never going to trigger this myself. If this check 
> is just a warning, I think we could be a little more aggressive in 
> merging this, since it shouldn't break anyone's workflows.

I think Eli's already decided the idea of checking for the existence of
files isn't a good one, because of the problem of deleting and renaming
files.

But also, I think having the script just warn is not useful.  Git
purposefully makes it impossible to correct mistakes in a commit
message, so we need to make sure the things are as correct as possible
to begin with.

-- 
Alan Mackenzie (Nuremberg, Germany).