EOL extension and patch.eol

[Colin Caughie]

> -----Original Message-----
> From: Martin Geisler [mailto:mg at mgsys.dk] On Behalf Of Martin
> Geisler
> Sent: 08 December 2009 10:13
> To: mhammond at skippinet.com.au
> Cc: Colin Caughie; mercurial-devel at selenic.com
> Subject: Re: EOL extension and patch.eol
>
> Mark Hammond <skippy.hammond at gmail.com> writes:
> > That last step should always do something sane for me, and
> > specifically, shouldn't (a) refuse to update or (b) show spurious
> > changes immediately after.  If it does, the path of least
> resistance
> > and pain is for me to grudgingly disable the extension too.
>
> You're certainly right that we should be careful about introducing
> spurious changes. Today 'hg update -C X' will always ensure a clean
> working copy with no output from 'hg status'. With the eol extension
> such a "clean" update might reveal inconsistencies where .hgeol
> demands
> one format, but a file is stored in another format.
>
> The easiest "solution" is probably to accept that 'hg update -C X'
> wont
> necessarily result in a clean working copy.
>
> However, we could also notice when files need a cleanup commit and
> *fix*
> the filters for that file until 'hg eolupdate' is run. Imagine we
> are on
> Windows and a file has LF in the repository where .hgeol says it
> should
> have CRLF. Fixing the filter for that file means that we change the
> filters from "CRLF <-> CRLF" to "LF <-> CRLF", which means that the
> file
> is still written in CRLF format in the working copy, but put back in
> LF
> format in the repository.

I like this idea, only I would prefer that any file in an unexpected format should be excluded from eol translation altogether, rather than trying to guess what kind of translation should be applied. This seems less accident-prone to me.

> We should probably output a warning on commit to let the user know
> that
> it is a good idea to run 'hg eolupdate' at some point.

I agree.

Colin


Latest News at: http://www.indigovision.com/news2009.php