(draft) style.9: Encourage style changes when doing significant modifications

[olce]

Summary

The rule of allowing style changes when about 50% or more of a file (or
group of files), coupled with the advice of avoiding stylistic changes,
could be interpreted as forbidding most style changes, even in heavily
modified functions.

In order to rule out that interpretation and ease transition towards our
prescribed style:

1. Clarify that avoiding stylistic changes concerns only "standalone" ones.
2. Actually encourage changing the style, and extend the cases where it is explicitly allowed to do so to any single logical unit as little as a function, keeping the existing ~50% of modified code as a rule of thumb.

When point 2 above applies, encourage to commit pure style changes
separately, and to add style-only commits to '.git-blame-ignore-revs'.

While here, regroup the paragraphs talking about style.

While here, rephrase the requirement on third-party maintained code to
be slightly less stringent.

[jhb]

share/man/man9/style.9

872

I would not say it's hard on the repo per se, but instead, it can make git blame harder to use (though there is some mitigation for that), and it can be disruptive to downstream consumers.

877

s/can/should/? Do we also want to document the git blame workaround here?

[imp]

share/man/man9/style.9

872

Yea, we have mechanisms to cope with blame, but downstream users have given the feedback repeatedly that style only changes are useless to them: they create more work w/o giving any value.

Maybe it's time to switch the focus here. Purely stylistic changes are hard for our ecosystem to swallow: they create more work for our downstreams and provide little to no benefit. They can also make tracing functional chanages harder.

878

We also have some files that we've decided, for whatever reason, to change the style in place: as we add new functions, we use the new style (often accidentally at first, because mike smith code is 4-space code and adding functions to that emacs automatically does 8-space-with-a-tab formatting). so in files like this, we've taken the logical group approach: I had 5 new functions and reformat 4 existing ones in a commit before the new function commit.

[olce]

• Amend in the direction of feedbacks.
• Move the whole block of text to the end of the section (but still before the recent C++ section).