Open Stack

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 <fungi at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150926/e4bc4109/attachment.html>