On Wed, May 27, 2026 at 15:09:21 +0200, Peter Krempa via Devel wrote: > On Wed, May 27, 2026 at 15:04:30 +0200, Jiri Denemark wrote: > > On Wed, May 27, 2026 at 11:05:02 +0200, Peter Krempa wrote: > > > On Wed, May 27, 2026 at 09:55:58 +0200, Peter Krempa via Devel wrote: > > > > On Wed, May 20, 2026 at 18:47:44 +0200, Denis V. Lunev wrote: > > > > > > [...] > > > > > > > > > > > Sigh ... I've meanwhile managed to introduce one more: > > > > > > > > +Radoslaw Smigielski <[email protected]> Radoslaw Smigielski via > > > > Devel <[email protected]> > > > > > > > > I'll add it to the patch before pushing and update the count; > > > > > > I've also installed a post-applypatch script for me so that I don't mess > > > up. I suggest for anyone reviewing upstream patches to do something > > > similar. > > > > > > $ cat .git/hooks/post-applypatch > > > #!/bin/bash > > > if [ "$(git show --no-patch --pretty='format:%ae')" == > > > '[email protected]' ]; then > > > echo '!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!' > > > echo '! !' > > > echo '! ERROR: munged email address in "Author" field !' > > > echo '! !' > > > echo '!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!' > > > fi > > > > Can't this be done as a push hook? Similarly to how we forbid pushing > > without a signed-off-by tag. > > Hmm, I wanted to say that it's not possible because the DCO requirement > is a checkbox in gitlab's UI, but I've noticed now that gitlab's branch > rules now have: > > Commit author's email > > [input box] > > All commit author's email must match this regular expression. If empty, any > email is allowed. > > So ... with a proper regex it should be possible to reject > '[email protected]'. I'll try it on a private branch first though > ...
So I had a closer look. Gitlab uses google's RE2 regex engine, which doesn't support negative lookahead. So creating a regex, which rejects a certain string is possible but extremely disgusting. Definitely not something I'd be willing to want to touch and so I'm not going to be putting it into the branch rule. Maintainers can use a hook and that, given the other option, is much more sensible.
