Alternatives to EOL extension

Benjamin Fritz fritzophrenic at gmail.com
Wed Jan 14 21:36:52 UTC 2015


On Wed, Jan 14, 2015 at 9:03 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>
> On 01/14/2015 03:40 PM, Carsten Fuchs wrote:
>>
>> I'm new to Mercurial, and was wondering what the proper way is to handle
EOL styles.
>> ...
>> ...
>> But what please are the alternatives?
>>
>> For my project, it would be ok to use a single EOL style under all
platforms, but how can I make sure that in a repository (either local
development or the remote "central" repository) mixed EOL-styles cannot
inadvertently be introduced?
>
>
> The alternative is to teach your users that they should pay attention to
what they commit, and that you should review everything carefully anyway
and reject anything that doesn't comply to your standards.
>

Related to that is the question: does it really matter in your project, if
mixed EOLs are introduced? Most tools I use these days don't care what
style the EOL is in, except for specific things that MUST be in one style
or another, like makefiles. I think one of the alternatives to using an
extension to enforce a line-ending style, is simply not enforcing a
line-ending style. Most of the time it won't matter.

I know that the "annotate" and "diff" commands can output some useless
stuff on specific revisions where line endings changed, but both of those
commands have options to ignore whitespace, which should filter that out on
the rare occasions somebody does something careless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150114/b2c74a45/attachment-0002.html>


More information about the Mercurial mailing list