This is the mail archive of the
mailing list for the glibc project.
Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 8 Nov 2018 20:38:58 +0000
- Subject: Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- References: <firstname.lastname@example.org>
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
Joseph S. Myers