Can I ask a different question - could we reject a few simple-to-check things on the push, like bad commit messages? For things that take 2 seconds to fix and do make people's lives better, it's not that they're rejected, it's that the whole rejection cycle via gerrit review (push/wait for tests to run/check website/swear/find change/fix/push again) is out of proportion to the effort taken to fix it.
It seems here that there's benefit to 72 line messages - not that everyone sees that benefit, but it is present - but it doesn't outweigh the current cost. -- Ian. On 25 September 2015 at 12:02, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-09-25 16:15:15 +0000 (+0000), Fox, Kevin M wrote: > > Another option... why are we wasting time on something that a > > computer can handle? Why not just let the line length be infinite > > in the commit message and have gerrit wrap it to <insert random > > number here> length lines on merge? > > The commit message content (including whitespace/formatting) is part > of the data fed into the hash algorithm to generate the commit > identifier. If Gerrit changed the commit message at upload, that > would alter the Git SHA compared to your local copy of the same > commit. This quickly goes down a Git madness rabbit hole (not the > least of which is that it would completely break signed commits). > -- > Jeremy Stanley > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev