EOL: patch.eol=auto setting

[alexrayne]

Martin Geisler ?????:
> I'm talking about putting the files in a version controlled file. That
> way settings will travel along when you push and pull, just like the
> ignore settings stored in the .hgignore file.
>
>   
,hgignore plays more simply and handy then .hgeol, because it not 
require commiting, and plays AS IS.

>> i imagin yet another examples:
>> 1)if people makes a mistake when cleanup commits and this mistake
>> detected too late, this require
>> repair commit on commit, and with every commit repository will grows
>> rapildly.
>>     
>
> No, don't be alarmed. First, you will only do one repair commit per
> file. You wont be doing it again and again... Second, the repository
> wont double in size. I just tried importing all files in Mercurial's own
> repository in a fresh repository. That gave me a .hg/store of 5.8 MiB. I
> then replaced \n with \r\n in all files and committed. The .hg/store
> folder was then 7.4 MiB. That was with 234,000 lines of code.
>   
this is because repository stores in compressed archive.
but the meaning of my argument is - WHY REPOSITORY SHOULD BE AFFECTED , 
IF IT CAN BE AVOIED, LEFT UNTOUCHED
and can be provided normal work without any cleanup.
i`m not against cleanup, but why not to allow user to chose what to do, 
make cleanup when he ready to do it.
the current trend of hgeol forces user to cleanup at 1st use.

>> 2) if repository shared between many peoples, some of them use hgeol,
>> some not. peoples used hgeol make cleanup commit - now how they are
>> push\pulling between each other? their changesets affects all the
>> repository.
>>     
>
> You should only use the eol extension if you actually think it is a good
> idea to have a consistent repository. Consistent in the sense that, say,
> all *.py files should have CRLF format. If you like to have an
> inconsistend repository, then don't use the extension :-)
>
>   
you think you say funny? i read - all who want somethig else fuckoff. i 
ask about help, but you wan`t hear my problem.
the solvation that you provide (cleanup commit) i can do without any hg 
extentions - by svn. and even without svn -
open text and save them with required eol. and win32text can do the same 
thig easy. saving .hgeol in repositore is not a big
effort (.hgignore i dont plase under revision)

> That being said, Mads Kiilerich did suggest that we could support using
> different EOL formats for different files in the repository. Something
> like this
>
>   [patterns]
>   foo.py = native/CRLF
>   **.py = native/LF
>
> which should mean that foo.py is checked out in native format and stored
> in CRLF format, whereas all other Python files are stored in LF format.
>
>   
as i understand it is not implemented yet. this is close to my request. 
i can propagate it to mentioned here style as

  **.py = native/auto

auto (or can be used another word), mean that repostory version format 
does not affected, and detected from revision file
(or cached any handy way) on any request.
> Please be more specific -- I can only guess what you mean by "smart
> encoding". The filters are already somewhat smart in the sense that they
> wont touch files that contain NUL bytes ("binary" files) or files with
> inconsistent line endings (a mix of \n and \r\n).
>
>   
i describe it higher as "auto" key: before to decode work file, detect 
required format from repository version.
if repository version has inconsistent eol, then here maybe choices 
(left undecoded, or correct consinency to required),
but at present need at least normal work with consistent files.