EOL extension and patch.eol

[Martin Geisler]

Colin Caughie <c.caughie at indigovision.com> writes:

> From: Martin Geisler
>
>> 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.

Ah, I didn't see that in the old discussion. I guess it was on IRC.

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

That is true. But the filter mechanism is broken or severely limited
anyway... you only get to install one filter per file.

A more general scheme is proposed here:

  http://mercurial.selenic.com/wiki/EOLTranslationPlan#Content_filtering_hooks

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

As far as I can see, the only consequence of a patch.eol=auto setting
would be that you would be able to import patches with the wrong EOLs.
The sequence would go something like that:

1) a.foo has LF in the repository

2) a clone is made and a.foo is written to working directory with LF

3) a patch in CRLF format is applied -- no problem, the patch is
   normalized to LF and a.foo is still in LF after patching.

Does that sounds correct?

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091208/17b7477e/attachment.pgp>