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