Alternatives to EOL extension

[Mads Kiilerich]

On 01/14/2015 10:36 PM, Benjamin Fritz wrote:
>
> On Wed, Jan 14, 2015 at 9:03 AM, Mads Kiilerich <mads at kiilerich.com 
> <mailto: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.

Yes - but why introducing it in the repository if the only sane thing to 
do is to jump through loops to ignore it anyway? Why spend space and 
thus time and get more churn for something that really doesn't matter?

A bigger problem than annotate and diff is that mergetools also will 
have to handle these random changes in line endings. Should the line 
endings be allowed to change randomly back and forth? Or should there be 
one well-defined default it just should apply before doing the actual 
merges? If so: that is pretty much what the eol extension does. It keep 
things simple by just always keeping it simple.

I agree it is better if everybody can agree on using tools that do it 
the same way. But IMO, if you are working cross platform and with 
different tools (especially MS tools), then you need some kind of 
tooling to keep things konsistent.

(I started implementing a similar extension that supports a subset of 
editorconfig.org settings. That can help taking care of other minor 
things developers just don't should spend time on, such as BOMs, 
space/tab indentation and trailing whitespace. I might even finish the 
extension ;-) )

/Mads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150115/51d39ffa/attachment-0002.html>