On Mon, Sep 11, 2023 at 9:43 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Mon, Sep 11, 2023 at 09:27:48AM -0400, David Malcolm via Gcc-patches wrote: > > On Sun, 2023-09-10 at 16:36 +0200, Guillaume Gomez wrote: > > > When going through the code, I saw a lot of trailing whitespace > > > characters so I decided to write a small script that would remove > > > them. I didn't expect there would be so many though... Not sure if > > > patch with so many changes are accepted like this or if I should send > > > more focused one. > > > > I'm not sure either. > > > > Some notes on the patch: > > IMHO testsuite shouldn't be touched at all, there are certainly tests > which test whether such sources are handled correctly. > > Non-C/C++ sources shouldn't be changed this way either. > > The ^L stuff should be preserved, not removed. > > And even with that, I'm not sure it is a good idea to change it because > it will be a nightmare for git blame. >
Some git hosting services have added support for special files to ignore revisions like this in git blame, for example, on GitHub, it's called .git-blame-ignore-revs: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ See for example: https://github.com/cooljeanius/highlight.js/blob/main/.git-blame-ignore-revs > The usual way of fixing up formatting if it was committed in a broken way > is only when one is touching with real code changes something, fixing up > formatting on it or around it is fine. > > If we decide to fix formatting in bulk, I think we should have a flag day > and change also other formatting mistakes at the same time (say 8 spaces > instead of tabs for start of line indentation (before first non-blank > character), = at the end of line except for static var initializers, etc. > But to make that worthwhile, it would be better to then have a pre-commit > hook that would enforce formatting. And, we haven't managed to come up with > something like that yet. > > Jakub >
