EOL extension

Mark Hammond skippy.hammond at gmail.com
Tue Dec 1 03:17:39 CST 2009


On 1/12/2009 7:38 PM, Dirkjan Ochtman wrote:
> Even if the damage has been done, you could commit a new changeset on
> top of it, to make sure the (or all branch tips) of the remote repo
> always have sane line endings (and I guess the scenario where people
> push one self-authored cset at a time is still pretty common). That
> still seems like a win to me.

I beg to differ - that isn't a "win" - that is "loss reduction" (ie, 
damage control) - and the damage control will always fall on Windows 
users.  I'm looking for damage *limitation*.  To go back to the SVN 
examples we have been using, the same damage control facilities are 
available there - they just don't need to be used in practice.

I think the term you used in the previous email - "frictionless" - is 
exactly what I am after.  I already work successfully with hg - just 
with lots of friction.  I'm more interested in reducing that friction 
than moving it somewhere else.  I see mixed-EOL repositories as a better 
outcome than one polluted with "fixing EOL" commits when attempting to 
push your already tested code (after all, most compilers/interpreters 
work just fine) - but I don't like seeing checkins/diffs which appear to 
touch every line of a file, when the reality is only 1 line actually 
changed.

An off-the-wall solution may simply be to make hg totally EOL agnostic - 
ie, for "hg diff" etc to only report/operate on the actual changes, 
ignoring any EOL changes which may have been made?  Obviously this goes 
beyond the obvious 'diff' (eg, merging), so I expect this would turn out 
to be non-trivial - but is the effective outcome I am after.

Cheers,

Mark


More information about the Mercurial-devel mailing list