Gert, thank you > We need to cover this in the style guide, to make clear which variant is preferred > (if the text fits into one line if putting it onto its own line, this is a different > story).
Indeed, it needs to be written down, including what to do with existing code on changes near around. In this case I had to follow Antonio suggestion about the breaks, previous version w/o them hasn't pass review. As for blame, most of git ui tools allows to traverse blame in depth, incl. tig - console git shell, anyway any refactoring brings the same issue. -- Best Regards, Vladislav Grishenko > -----Original Message----- > From: Gert Doering <g...@greenie.muc.de> > Sent: Saturday, October 3, 2020 12:33 AM > To: Vladislav Grishenko <themi...@yandex-team.ru> > Cc: openvpn-devel@lists.sourceforge.net > Subject: [PATCH applied] Re: Selectively reformat too long lines > > Your patch has been applied to the master and release/2.5 branch. > > I am not particularily happy about merging this sort of "cleanup" > patch so late before 2.5 release - *but* I have very carefully checked that it's > really all just re-wrapping long function calls, or long text strings, so the danger > to 2.5 stability is minimal. OTOH, not merging this to release/2.5 means more > work for all future bugfixes that happen to be close enough to one of these > changes so the "diff context" is changed. So, in it goes. > > As a side note - but too late to stop it, as Arne and Antonio have spoken - I do > not think this sort of change is actually making the code *more* readable: > > - msg(M_WARN, "DEPRECATED OPTION: --inetd mode is deprecated " > - "and will be removed in OpenVPN 2.6"); > + msg(M_WARN, > + "DEPRECATED OPTION: --inetd mode is deprecated and will be removed > " > + "in OpenVPN 2.6"); > > it's basically making 3 lines out of two, while the text still needs to be wrapped. > So instead of "two lengthy" lines, we now have "one very short line, one very > long line, and one short line again" - I find that *less* readable, and since the old > code conformed to the 80 character limit, it's commit noise which makes "git > blame" harder to follow, with questionable benefit. > > We need to cover this in the style guide, to make clear which variant is preferred > (if the text fits into one line if putting it onto its own line, this is a different > story). > > > commit a5409c0d34bf02cacdee61d61ba7b3e1f72e132f (master) commit > c055e28654f340c617a2b0eece7fa28c79c1a9fc (release/2.5) > Author: Vladislav Grishenko > Date: Thu Sep 24 14:10:04 2020 +0500 > > Selectively reformat too long lines > > Signed-off-by: Vladislav Grishenko <themi...@yandex-team.ru> > Acked-by: Arne Schwabe <a...@rfc2549.org> > Message-Id: <20200924091004.29065-1-themi...@yandex-team.ru> > URL: https://www.mail-archive.com/openvpn- > de...@lists.sourceforge.net/msg21083.html > Signed-off-by: Gert Doering <g...@greenie.muc.de> > > > -- > kind regards, > > Gert Doering _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
