EOL: patch.eol=auto setting

[alexrayne]

Martin Geisler пишет:
> alexrayne <alexraynepe196 at lavabit.com> writes:
>
>   
>> Martin Geisler пишет:
>>     
>>> First, ensure you have a clean working copy: 'hg status' should give
>>> no output. Then add the .hgeol file and commit it. You'll then see
>>> that 'hg status' reports lots of changed files -- those are the files
>>> that are stored with CRLF in the repo. They show up as changed since
>>> the extension would like to convert them to LF in the repo.
>>>
>>> Ideally, you should be able to commit the converted files at the same
>>> time as you commit .hgeol -- see this TODO:
>>>
>>>   http://bitbucket.org/mg/hg-eol/changeset/6fd8c3e6ec1f/#chg-eol.py_newline129
>>>
>>>       
>> Do you wanna say that after that i apply hgeol settings i must
>> recommit all files that are commited in not suitable format for you?
>>     
>
> The goal of the extension is to ensure two things:
>
> 1) Files have the correct EOL format in the repository.
>
> 2) Files have the correct EOL format in the working copy.
>
>   
>> this is devaluate hgeol mean to zero for me - and not only for me,
>> because with this commit i loose ability of changes propagation
>> through history,
>>     
>
> No, you wont. The extension will set patch.eol=auto for you, which means
> that newlines are ignored in patches. In other words, if the big cleanup
> commit changes a file from LF to CRLF in the repository, then you can
> still apply a patch made using the LF version of the file after it has
> been converted to CRLF.
>
>   
>> and even is i not need this propagation, i saw ropository with about
>> 12000 files (most is text) - such commit just duplicate all of them to
>> repository.
>>     
>
> Sure, that's just tough luck :-) If you want to do the cleanup, then
> you'll need the commit. Perhaps you haven't seen that you can configure
> repository EOL format yourself? If you add
>
>   [repository]
>   native = CRLF
>
> to the .hgeol file, then the files configured as native will be stored
> in CRLF format in the repository.
>
>   
>> and even if i can do such commit, what advantages hgeol least vs
>> win32text - it is doing the same things, and it is stupid too.
>>     
>
> The main advantage is that eol keeps its configuration settings in a
> version controlled file.
>
>   
i can store win32text settings in repository local hgrc file too.


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

the reasons why repository format should be untuched maybe different for 
other peoples.

anyway impementing the basic smart encoding is not very difficult 
feature - must be implemented one more testing of
retrieved repository version.
imho, this feature can be very useful just because it allow repository 
be untouched, and therefore provide people feeling
of safety - without cleanup commits there no trash changesets or 
mistakes go into repository. and it is real advantage vs win32text.

maybe i must say PLEEESSSSEEE, provide smart encoding in hgeol.