Line ending translation extension

[Mads Kiilerich]

To avoid nicely threaded but exponential growth in the number of 
messages I will respond to several statements here:

On 09/07/2009 03:10 AM, Dj Gilcrease wrote:
> Proposal, add decode to the patch.eol config setting so it will use
> the decode filters to normalize the file, and if the particular file
> does not fall under a filter it would default to strict
>    

I agree(d):
http://markmail.org/message/bg2d6jckogx43qzm


On 09/07/2009 06:26 AM, Steve Borho wrote:
> Certain well-known merge tools (aka kdiff3) will write out merge
> results in the machine default line endings regardless of the line
> endings of the source files.  fixeol detects that the line endings
> were changed by the merge tool and recovers them to the line endings
> of the first parent.
>    

It is my understanding (from the discussion some time ago - not from 
reading the code) that it also deals with the situation of having a CR 
file and then apply a patch which happen to be CRLF. I might be wrong.


On 09/07/2009 09:56 AM, Martin Geisler wrote:
> Yes, that's why the prototype I posted support a section like this in
> the .hgeol file:
>
> [repository]
> native = CRLF
>    

Ok - you mean "repository" litterally. I assumed that it was for 
overruling the platforms default understanding of "native encoding". I 
think such functionality will be needed too. For example to create a 
tar-ball for "the other" platform.


On 09/07/2009 10:47 AM, Paul Moore wrote:
> There's a lot of FUD in this thread, and I'm concerned that I might be
> adding more here, but nevertheless...
>    

Yes. We should all do like Martin and come up with some code instead of 
arguing. Good advices are good, but if someone thinks they have a 
problem and wants it solved in a certain way then they should have the 
freedom to do that.


On 09/07/2009 11:10 AM, Stephen J. Turnbull wrote:
> This is no different from the current situation, where refusal to work
> leaves us with win32ext, except that the not quite working
> unmaintained extension might be a marked improvement over win32ext.
>    

I haven't met anyone who thinks win32text is a good solution. It is 
usable, but it has some problems and is not elegant. I don't think 
anybody would object if we could use this opportunity to come up with 
another and better alternative.

I have no doubt that an extension which works better than win32text will 
get more usage and more love from the users and maintainers.

/Mads