EOL extension and patch.eol

Mads Kiilerich mads at kiilerich.com
Tue Dec 8 06:06:02 CST 2009


Martin Geisler wrote, On 12/08/2009 11:13 AM:
>>> It will also not be enough to changing line-endings by applying a
>>> patch to foo.py -- one must instead patch both .hgeol and foo.py in
>>> lock-step. Actually... the way I envision things, you wont have to
>>> touch foo.py in your patch to update it's line-endings: patching
>>> .hgeol should be enough to make the commit fail:
>>
>> Or just disable the EOL extension?  I think we need to ensure we don't
>> end up in the scenario where a user who has not enabled the EOL
>> extension manages to "break" usage for those who have.  Eg:
>>
>> * I send \r\n terminated patch to linux user without EOL
>> * Linux user applies without noticing mixed line endings.
>
> If the file has \n line endings, then the Linux user wont be able to
> apply the \r\n patch directly (the "extra" \r in all lines means that
> the patch wont be able to find it's context).

We are trying to establish a new invariant for the repository, so all 
clones of this repository on all platforms should use the extension - 
also on Linux. Won't that solve the problem?

These poor guys on Windows have enough problems already, so we shouldn't 
blame them for the interoperability problems. ;-) In all our examples 
let us imagine that python.org decides to use and enforce CRLF in all py 
files in their repo. That will make us spoiled *nix users feel the pain ...

>> * I attempt to update my working tree.
>>
>> 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.
>
> In other words, if you add a new line to the file, your patch will
> contain only the addition of that new line and the file is kept in LF
> format in the repository until someone updates it. You update it by
> running 'hg eolupdate' which resets the filter to "CRLF<->  CRLF", after
> which the (unchanged) file appears as modified in the working copy. It
> is modified because the next commit will change all line endings from LF
> to CRLF in the repository.
>
> 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.

Note that the keyword extension has the kwshrink and kwexpand commands, 
apparently for the same reasons.

/Mads


More information about the Mercurial-devel mailing list