EOL extension and patch.eol

[Mark Hammond]

On 5/12/2009 9:20 PM, Martin Geisler wrote:
> Hi guys,
>
> I've pushed this test case to Bitbucket:
>
>    http://bitbucket.org/mg/hg-eol/changeset/ef070315d614/
>
> As the commit message says, I believe it is wrong since it cannot handle
> the case where we have to change patch.eol in a single patch. The code
> will actually normalize all EOLs to whatever the platform native setting
> it, also in binary files.
>
> I searched back a bit and found
>
>    http://selenic.com/hg/rev/ac92775b3b80
>
> which introduces the patch.eol setting. I also found
>
>    http://markmail.org/message/acmrduwld75drnw3
>
> by Colin which looks superior since I believe it does apply the filters
> on a per-file basis. I believe that is the root problem: the patch.eol
> setting is global to all files in a single imported patch.
>
> Does anybody have a suggestion?

I'm not the familiar with all the issues, but I think a reasonable 
underlying assumption is that regardless of the line-endings in a patch, 
the intention will be for the patch to be applied as EOL agnostic "text" 
- I think it is the truly exceptional case where a patch should be 
applied such that it causes mixed line-endings - and in those cases, it 
would be reasonable to expect things have been configured such that the 
file is treated as "binary".

In particular, if my working tree uses CRLF line endings and I send a 
patch to a non-Windows user, both me and that user will expect the patch 
to be applied by ignoring the EOL in the patch.  Similarly in reverse.

So this leads to me 2 observations:

* It should not be necessary to set various different options to get the 
correct behaviour, so I don't like the apparent requirement in the first 
patch to set a [patch] option.  This should "just work", particularly 
for people on Linux who have ignored all EOL issues (ie, not configured 
the EOL extension, let alone the [patch] option), but receive patches 
from people who have.

* It seems reasonable to me that hg "unconditionally" ignore the EOL in 
a patch itself, except for files which are "binary".  Thus, looking at 
the EOL convention of each individual file doesn't seem necessary.  It 
may be desirable for implementation reasons, but it shouldn't affect the 
outcome of the patch operation.

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... :)

Hope this helps,

Mark