This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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
coding.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]