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: DJ Delorie <dj at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 08 Nov 2018 13:56:27 -0500
- Subject: Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
Joseph Myers <firstname.lastname@example.org> writes:
> or specify a revision with "git blame" to look at history before that
git blame without a revision will blame the formatting changes, since
they'd have touched many lines. This is probably my biggest reason to
avoid formatting changes - it hides who last touched a specific line,
adding extra work to track down algorithmic changes.
> Florian noted the possibility of using commit hooks to enforce a
> particular style for new / changed lines, but that would only detect
IMHO if we decided to enforce a style, we should (1) bulk-format the
sources through, say, indent, and (2) auto-bulk-format on commit also.
If we're going to rely on some programmatic style enforcement, we should
only do so IF it removes the burden of that enforcement from the user.
If the burden remains on the user to format the style, any programmatic
blockades will be seen as annoyances and stumbling blocks, not aids to
> 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.