[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mistakes in commit log messages
From: |
Alan Mackenzie |
Subject: |
Re: Mistakes in commit log messages |
Date: |
Wed, 12 Apr 2023 09:32:30 +0000 |
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).
- Re: Mistakes in commit log messages, (continued)
- Re: Mistakes in commit log messages, Jim Porter, 2023/04/15
- Re: Mistakes in commit log messages, Eli Zaretskii, 2023/04/16
- Re: Mistakes in commit log messages, Jim Porter, 2023/04/16
- Re: Mistakes in commit log messages, Michael Albinus, 2023/04/16
- Re: Mistakes in commit log messages, Eli Zaretskii, 2023/04/16
- Re: Mistakes in commit log messages, Michael Albinus, 2023/04/17
- Re: Mistakes in commit log messages, Jim Porter, 2023/04/21
- Re: Mistakes in commit log messages, Eli Zaretskii, 2023/04/15
- Re: Mistakes in commit log messages, Alan Mackenzie, 2023/04/12
- Re: Mistakes in commit log messages, Eli Zaretskii, 2023/04/12
- Re: Mistakes in commit log messages,
Alan Mackenzie <=