This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- From: Jeff Law <law at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 8 Nov 2018 12:08:01 -0700
- Subject: Re: Indentation, tabs, and spaces (was re: [PATCH] support: Implement TEST_COMPARE_STRING)
- References: <xnd0rftn38.fsf@greed.delorie.com>
On 11/8/18 11:56 AM, DJ Delorie wrote:
>
> Joseph Myers <joseph@codesourcery.com> writes:
>> or specify a revision with "git blame" to look at history before that
>> revision.
>
> 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.
This where I'd like to go for GCC as well. But I haven't had much
success with convincing folks.
FWIW, I thought glibc already had some hooks to catch formatting nits
(like trailing whitespace).
Jeff