On 26-01-2026 10:38:06 +0800, Kevin J. McCarthy wrote: > You'll notice in the second commit I declined at that time to do > anything about the tabs vs spaces indentation split. The code base is > fairly evenly divided between the styles. However, if we now use git > send-email more for review, that leads to readability issues. > > I don't have a rabid preference about this, but I personally like > spaces, and if we're going to go one way or another, I'd like to convert > the code base to spaces, using e.g. "expand" or similar utility.
+1 for using solely spaces for indentation, stopwidth/tabstop = 2. > To avoid making stable branch commit merges back to master a nightmare > during 2.3.x maintenance, I'd prefer to do this close to the end of the > 2.4.0 development cycle. If someone is interested in doing this, please > speak up, otherwise I'll just run "expand" and commit it close to the > end of the cycle. Why don't you do it now, and declare 2.3.0 a "last" release that will not receive any updates. If there's a problem, that needs resolving that is too big not to easily backport to 2.3.0, just release 2.4.0. I think with the effort to get things going again, perhaps it is nice when all of that can be done immediately on a codebase that's formatted in the way it should be. A commit hook can perhaps even ban commits to source/header files with lines that start with whitespace containing hard tabs in them. Thanks, Fabian
