Hi John, I'm sorry that this caused complications in downstreaming changes.
Nevertheless, some of your words look like quite the surprise. > > commit 7487932f4fbc5a71231d3b1fc93d160253f38c83 > > Author: Olivier Certner <[email protected]> > > AuthorDate: 2026-06-02 10:01:05 +0000 > > Commit: Olivier Certner <[email protected]> > > CommitDate: 2026-06-04 11:49:26 +0000 > > > > assert.h: style(9): Space after #define, between #endif and comment > > > > style(9) still allows TAB after #define but this is a historical > > artifact and by far the minority of uses cases. Going forward, we > > would > > like to promote the use of a single space, as it allows alignment to > > survive line prefixing (such as in diffs). > > It is not "by far the minority" and is still widely used. Excluding contrib > it > is still about 1/3 of the cases in the tree. I had done some statistics and, excluding contrib, I got a number much closer to 1/4 than 1/3 (165316 against 439359 on main in the middle of this week). Maybe "by far the minority" was too strong. It remains that statistics are unequivocally biased towards spaces. > This was not worth yet another commit to this file absolutely destroying git > blame. This file has seen a series of 6 commits in the past days, of which only the last one is mine, and importantly it only changed lines already touched by the preceding commits. Certainly, one more commit is always one more annoyance, but is "absolutely destroyed git blame" an adequate characterization? > Please cool it a bit on going on holy wars over pushing for changes to > historical style and then committing style-only changes. Changes I've proposed have always been through srcmgr@ (I'll specifically come back below to the "Going forward, we would like to promote (snip)" quote from the above commit message). There have been only a few of them, of which only one was enacted (see changelog for style(9)), and in particular it was approved by you. It is about: "Encourag(ing) style changes when doing significant modifications" (full commit at https://cgit.freebsd.org/src/commit/?id=af2c7d9f6452f2281a). Let me quote the relevant part: """ On the other hand, when a significant portion, usually about a half, of some logical unit of code, be it a function, group of functions, file or group of files, is going to be modified, developers are encouraged to amend the style of the whole unit as described in this document. In this case, style changes to otherwise unmodified code should be committed separately. Style-only commits should be added to the file .git-blame-ignore-revs at the top of the source repository to hide them from ‘git blame’. """ assert.h, as of 439710cf003b (last commit before my change), is 115 lines, actually only 80 if you omit the license block. Commits since May 30th changed 46 of these (only counting the final result, not intermediate churn). That looks like about a half. Certainly, it would have been better that the style changes I finally made had been done as part of the actual code changes and not a separate commit. And, actually, they initially were, but were then reverted because of an objection that the historical style was TABs. That's the only reason that prompted me to intervene: That the argument used was in contradiction with style(9) (and had been since 2021). If that was only for the TABs, I would not have done anything (TABs are not forbidden there). By contrast, I thought it important to counter propagation of false statements regarding style(9), and acted promptly so that my own commit would be close to the other ones temporally so as to minimize downstreaming disturbance (which is the spirit of the quoted text above). Finally, prior to committing, my change was put into review and approved, in particular by imp@. The "Going forward, we would like to promote the use of a single space, as it allows alignment to survive line prefixing (such as in diffs)" statement in the above commit message was more about my own opinion initially, but then I received some backing by imp@, and in the end kept that sentence (perhaps I shouldn't have). The next natural step is to raise that potential change (encouraging a single space in new code; not even making it compulsory) at some next srcmgr@ meeting. "Holy wars"? Regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
