Created attachment 238381 [details] fix proposal for check_portepoch to fix various issues with it I was editing dns/dnsmasq-devel 2.88rc3, to upgrade to rc5, and removed a PORTEPOCH comment. This tripped up check_portepoch, which cannot cope with a situation that git renders PORTEPOCH diffs that do not relate to ^PORTEPOCH=23 lines, and it printed [pre-commit] dropped PORTEPOCH in dns/dnsmasq-devel/Makefile So, because I was editing PORTEPOCH comments, git was emitting the lines, but grep was not picking them up. Right. And then the first check for the exit 1 path was simplistic and just assumed "no new portepoch, we're broken". Untrue. To fix, only complain about an empty PORTEPOCH if we had one before. If both old and new are empty, we may be safe, so do not complain and do not error out. Also note that GNU grep complains about the regexps, because it runs without -E option, but the basic regex has \- (you never escape -) and \+ (which has reverse meaning, and you do not want to match multiple ^ anchors instead of matching the literal +), so fix that, too, and be stricter to only look at ^PORTEPOCH lines that have a = somewhere.
while here, should not we redirect such complaints to stderr with adding >&2 to echo? Just add that when committing.
hm, given comments are the issue maybe do "^-[^#]*PORTEPOCH" in the regex instead of the "=.*"? Because if you had a comment ala # previously this was PORTEPOCH=3 with the old orgin foo/bar that would still trip it erroneusly. mfg Tobias
(In reply to Tobias C. Berner from comment #2) A diff comment line would not be matched by a *WORKING* grep regexp. The old regexp was tripping grep up by ^\+PORTEPOCH, which caused GNU grep to ignore this whole stuff. A comment would be ^-#.*PORTEPOCH or ^+#.*PORTEPOCH as basic regular expression (grep without -E) and would not match.
(In reply to Matthias Andree from comment #3) No, that would only match a line that stats with a comment my suggestion would be to match lines starting with +- and containing PORTEPOCH=, but no '#' prior to the PORTEPOCH string.
(In reply to Tobias C. Berner from comment #4) How far away are we from "make -C ... -V PORTEPOCH" now?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=414b5c61645669a346fc817e0b5852c265b96187 commit 414b5c61645669a346fc817e0b5852c265b96187 Author: Matthias Andree <mandree@FreeBSD.org> AuthorDate: 2022-11-27 12:51:51 +0000 Commit: Tobias C. Berner <tcberner@FreeBSD.org> CommitDate: 2022-12-18 08:58:17 +0000 .hooks/pre-commit.d: unbreak EPOCH checker dns/dnsmasq-devel as of 2.88rc3 contained a comment about PORTEPOCH, which I removed in the 2.88rc5. This tripped up the checker because it assumed that if git yielded lines containing PORTEPOCH, then it must have been PORTEPOCH= or similar lines. Untrue in my case. It was printing [pre-commit] dropped PORTEPOCH in dns/dnsmasq-devel/Makefile To solve, only pick out PORTEPOCH diffs that are actual assignments, and if the new PORTEPOCH is empty, and the old one is also, ignore this condition (previously we would exit 1, which is bogus). Also, grep without -E should not have \ in front of - or +. FreeBSD 13.1 grep is fine, but GNU grep ignores those backslashes noisily (and I have prepended it to PATH) and emits warnings. PR: 268024 .hooks/pre-commit.d/check_portepoch | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)