EOL extension and patch.eol

[Mark Hammond]

On 7/12/2009 10:53 PM, Martin Geisler wrote:
> Yes, it seems to me that this is the right approach: we should both
> generate and accept patches as if there were no EOL translation going
> on. That will unfortunately mean that 'hg diff>  p.txt' will produce a
> file in LF format under Windows. Is that a concern?

A little :)  Depending on the tools, it is then possible "patch < p.txt" 
or a variation may create mixed line endings in the working tree copy. 
The target of the patch may not even be under hg.

That said though, I wouldn't consider that to be a "blocker".  For my 
interest though, does hg reopen stdout as binary?  Note that the script:

import sys
sys.stdout.write("foo\nbar\n")

When executed as "python foo.py > foo.txt" will cause foo.txt to have 
\r\n line endings.

>>> IOW - it seems there is one "obvious" outcome when applying a patch
>>> to text files - that the file will have the same EOL before and
>>> after. Except when trying to clean up the mess in a mixed EOL repo
>>> though... :)
>>
>> I think that was the basic argument against -- ignoring line endings
>> fails if you have a patch that changes line endings, or that operates
>> on a file with mixed line endings.
>
> Hmm, if that is the problem, then I would be okay with saying that you
> cannot have files with mixed line-endings under the control of eol.

I think I agree in general - although we need a path that allows EOL to 
be used on an existing repo *before* all line endings have been cleaned 
up, as otherwise it will be hard for one or 2 developers to experiment 
with EOL before they have the "buy-in" from the rest of the team (or 
don't have push permissions, etc)

> 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.
* 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.

Cheers,

Mark