Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 8 Nov 2018, DJ Delorie wrote:

> IMHO if we decided to enforce a style, we should (1) bulk-format the
> sources through, say, indent,

There are enough weird things with macros involved that I suspect indent 
would make a mess of - formatting fixes other than changing tabs to spaces 
would need to be done in smaller, more readily reviewable pieces rather 
than globally trusting the results of indent.  (Changing tabs to spaces is 
pretty safe if you do a before and after comparison of installed stripped 
shared libraries for all build-many-glibcs.py configurations.)

> and (2) auto-bulk-format on commit also.

git doesn't allow the central repository to say how clones should be 
configured (so it can't set filter.*.clean), and once a commit has been 
created in a clone and an attempt is made to push it, the push can succeed 
or not, but the central repository can't choose to make changes to the 
commit contents.  So auto-bulk-format on commit isn't reliably possible 
(whereas you can reject pushes for bad formatting, and can make the glibc 
testsuite have a test that fails for bad formatting so it doesn't get as 
far as an attempt to push).

> > With a consistent style in a project, you can set your editor to default 
> 
> Except many of us contribute to multiple projects with differing styles.
> One editor setting cannot solve that problem.

But it can be set based on e.g. the directory in which editing (and we can 
put configuration for common editors in the glibc source tree, such as 
.dir-locals.el).

-- 
Joseph S. Myers
joseph@codesourcery.com