On Wed, Jul 11, 2018 at 11:52 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Mon, 09 Jul 2018 10:40:22 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > >> Hi, >> >> We currently don't enforce any particular standard for e-mail addresses >> for developers committing to gentoo.git. FWICS, the majority of >> developers is using their @gentoo.org e-mail addresses. However, a few >> developers are using some other addresses. >> >> Using n...@gentoo.org e-mail addresses generally causes problems >> in accounting for commits. For example, our retirement scripts can't >> detect commits made using non-Gentoo e-mail address. My dev-timeline >> scripts [1] account for all emails in LDAP (which doesn't cover all >> addresses developers use). FWIK gkeys accounts for all addresses >> in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump >> through to workaround bad practice. >> >> Therefore, I'd like to start enforcing (at the level of the hook >> verifying signatures) that all commits made to gentoo.git (and other >> repositories requiring dev signatures) are made using @gentoo.org e-mail >> address (for committer field). >> >> Is anyone opposed to that? Does anyone know of a valid reason to use >> n...@gentoo.org address when committing? >> >> [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html >> > > There's one fun problem here technologically for proxy-maint, but > getting the conditions right for it to occur happen very rarely. > > 1. Assume the proxied maintainer has a git repo, where they commit > themselves. > > 2. Assume their proxy has said git repo as an alternative remote, for > which they relay work. ( That is, they work closely together directly > instead of via github pull requests and textual patches ) > > 3. ::gentoo is quiet, and the proxied maintainer has rebased their own > work on top of ::gentoo, setting Committer: metadata and signing > commits. > > Then, in that situation, it is trivial for the proxy to relay those > commits verbatim to ::gentoo, without changing either Committer: or > signature data. > > Standard git tools will not attempt to even *change* these commits even > with an explicit rebase, because Git will detect that nothing needs to > change, and will no-op the rebase, leaving Committer and Signatures > intact, degrading to a fast-forward merge. > > It seems like it would happen not-very-often, but ... > > git log --show-signature --format=fuller --committer=".*@\([^g]\|g[^e]\)" > > Well, the last example happened in 2017, so maybe something happened > *since* then that prevented this situation occurring via other means? > *shrug* > > > commit 76eb43412b532a045d92d524dfa5ed1b1bcca671 > Author: Michael Mair-Keimberger <m.mairkeimber...@gmail.com> > AuthorDate: 2017-10-02 02:47:28 +1300 > Commit: Michael Mair-Keimberger <m.mairkeimber...@gmail.com> > CommitDate: 2017-10-10 07:45:09 +1300 > > To the best of my knowledge, Michael isn't a Gentoo Dev.
This was incorporated into the master branch via a merge commit, not a fast-forward or a rebase. See 6711d4f96985b0797c1803cd6f05e5a1410c1018. We have generally discouraged merge commits, but they do occasionally happen.
