EOL extension and patch.eol

Paul Franz theandromedan at gmail.com
Tue Dec 8 10:12:51 UTC 2009


Colin Caughie wrote:
>> -----Original Message-----
>> From: Martin Geisler [mailto:mg at mgsys.dk] On Behalf Of Martin
>> Geisler
>> Sent: 07 December 2009 11:53
>> To: Colin Caughie
>> Cc: mhammond at skippinet.com.au; mercurial-devel at selenic.com
>> Subject: Re: EOL extension and patch.eol
>>
>> Colin Caughie <c.caughie at indigovision.com> writes:
>>     
>>> I think you can guess what my suggestion would be... :)
>>>       
>> Yeah :-) But perhaps there is a simpler solution: we could add a new
>> patch.eol setting: 'restore'. That setting means:
>>
>> * take note of EOL-type in file
>> * ignore EOLs in file and in patch while applying the patch
>> * restore EOLs to original type
>>
>> The idea is that with the eol extension, then we don't care about
>> line
>> endings in files or patches. So we can set patch.eol=restore in
>> general.
>> If a patch was supposed to switch line-endings, then that will be
>> ignored in the file. But if the patch also updated .hgeol, then
>> we're
>> good: the file will be committed with the requested line-endings.
>>     
>
> Yes, Patrick and I discussed a "patch.eol=auto" mode that would do exactly this. We agreed to leave it out of 1.3 though as we could solve most people's problems without it. It would probably do the job for anything other than files with mixed line endings.
>
> All the same it does seem a shame to resort to something that changes the rules for _all_ files when we are introducing a nice pattern-based rule mechanism to select a subset of files in the repo for eol translation.
>
> Ideally I'd like to be able to say "all C++ and Python files should be native eol, but please leave .foo files alone even though they look like text". If I say that in my .hgeol file, I expect .foo files to be treated exactly as they would if I hadn't enabled the eol extension or changed the patch.eol setting from its default of "strict".
>
> Colin
>   

An excellent example is Oracle SQL scripts. They should always use Unix 
EOL because then they will run on both Windows and Unix clients.

Paul Franz




More information about the Mercurial-devel mailing list