Date: Fri, 17 Oct 2025 00:38:20 -0700 From: "Enji Cooper (yaneurabeya)" <yaneurabeya@gmail.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Rick Macklem <rick.macklem@gmail.com>, "David E. O'Brien" <obrien@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 0050289464fa - main - style(9): white space after ; and around binary operators Message-ID: <AA044313-BA72-44D8-9AA4-CADAD7A11017@gmail.com> In-Reply-To: <16835444882475995d82a23078996276@Leidinger.net> References: <202510162205.59GM5ZvD042942@gitrepo.freebsd.org> <CAM5tNy68Gpj0qKV2HyRQ5t1PqchXtfi5bh53QK874aGM9WiEPw@mail.gmail.com> <CAM5tNy4pCN6nUbcr9W8-%2B2MLaULDMpK_DR%2B9Yye4t6aPvrbK9Q@mail.gmail.com> <16835444882475995d82a23078996276@Leidinger.net>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On Oct 16, 2025, at 10:29 PM, Alexander Leidinger <Alexander@Leidinger.net> wrote: > > Am 2025-10-17 01:29, schrieb Rick Macklem: >> On Thu, Oct 16, 2025 at 4:21 PM Rick Macklem <rick.macklem@gmail.com> wrote: >>> Please be aware of the following snippets from "man 9 style": >>> In general code can be considered "new code" when it makes up about 50% >>> or more of the file(s) involved. This is enough to break precedents in >>> the existing code and use the current style guidelines. >>> Stylistic changes (including whitespace changes) are hard on the source >>> repository and are to be avoided without good reason. >>> rick >> Just to be clear, I am not asking that this commit be reverted. >> I am just suggesting that you be aware that style(9) changes to >> extant code is not, in general, encouraged, afaik unless you are >> re-writing a large portion of the code (over 50%). > > Does someone remember why? We have now the possibility to exclude commits from the VCS attribution of lines to commits (git blame), as such, does the reason of not doing it still hold? Hi Alexander, I’m not sure about the percentage Rick mentioned, but I think Mark’s comment about avoiding merge conflicts is a key point (for FreeBSD as well as downstream consumers of FreeBSD. Unnecessary churn can also make reconciling changes with other sources, e.g., NetBSD, OpenBSD, more difficult for little to no gain. Cheers, -Enji PS Has anyone tried running `clang-format -i` on these files to see how in compliance they are with style(9) *ducks to avoid flying fruit*? [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkHfexGRJ3gYRdA2gGpE5DjPsNJgFAmjx8mwACgkQGpE5DjPs NJgPNxAAiHOrHvdLe3+SPeNz2kwegiCsJAc8upxKEtXjdfxiTVePizzd1o7ofcjU dQTXGU7T+r5W2PsdWz6NZG+ZksMBcZwJUxZPeBTkPqC2hYEtx9LWJBQRsim+ccU7 btvcDl/R7k53O8nw0DDc5jxKLY48ewHaDnPJ7juUiPkqcXCQnlUj678lLJ5Xehm6 24gSvqHjYKvxDTOXq4bSjBrfW2waz7m3b4RyyngvZnHYR1s9Llce1Z5VoR8v8g/f 49a1Wl+mAJl2vrFhGZvLnDBS5DKCNujW8MklofxIZjaVqTT6S40uRFVIG/Z/8B7C CdmPZjk9Y18L43TK5lSrkZpfaMcFkfF8eOxzXIcVI3eHJ0POs+ogSwr70aG8ohxH 3fPMeRS7WOpyt+rfSGcpFkbzKSPEDw/tmAZ7fWWwb+82EJSG65BmqgnUTp4urnsU x0MHbBcysigOFRTiqADmwWLHZzJk0bH3VrxIXf3SKuJu+iTe6YptUVVGJ18qmdxQ NmuTTVKNLaljSCTiKOD7J+aEFQhFOQTA3khD5xNkpftYIGHcRHlbgHXR/24/JQN5 54xcHWtOFhdwsXtQplCcc1GiOcve42x0zJ/f1ALuf41J/uQsDqaIzYfDs2XhixjI SBP4eiJdL3rAFuOQnT7kljg+HyFlsaCbNVIqii5LAXueqZB/ouU= =kw5l -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA044313-BA72-44D8-9AA4-CADAD7A11017>