[Python-Dev] PEP 385: the eol-type issue

[Mark Hammond]

On 5/08/2009 4:50 PM, Ben Finney wrote:
> Mark Hammond<skippy.hammond at gmail.com>  writes:
>
>> On 5/08/2009 3:56 PM, Ben Finney wrote:
>>> Mark Hammond<mhammond at skippinet.com.au>   writes:
>>>
>>>> Let's say I make a branch of the hg repo, myself and a few others work
>>>> on it committing as we go, then attempt to merge back upstream. Let's
>>>> say some of the early commits on that clone introduced "bad" line
>>>> endings.
> […]
>>
>> The problem is the sequence of events happened in the first place. An
>> extra burden is placed on the developer that will quickly get
>> tiresome. I wouldn't personally be happy if that workflow became the
>> norm.
>
> Ah, okay. In that case, the ultimate “problem” is that OS vendors
> entrenched their incompatible line-ending conventions instead of
> choosing a single standard. Any line-ending burden borne by developers
> is a result of that.

Yeah - this happened around 1964 if wikipedia is any guide.

>
> If things were different, they'd be different. However, we live with the
> legacy of that stupid set of decisions and have no real option to
> resolve it permanently short of deprecating entire vistas of tools (or
> even entire operating systems).

Agreed - so let's not solve it permanently.

...
> It's not a simple thing to solve, and many clever people have tried over
> the decades.

As already mentioned in this thread, a capability similar to what svn or 
cvs offers would be sufficient.  While a DVCS does offer unique 
challenges, it seems to me that doing something at commit time without 
requiring magic hooks be configured would go a long way to addressing 
the problem.  Magic hooks on the official repo would then be considered 
the final fallback defense, but should rarely be invoked.

> At some point, the decision about how to handle line endings in
> cross-platform data needs to be punted to a human for a
> context-sensitive assessment, since (as can be seen) the above list of
> requirements is internally inconsistent and can't be relegated to a
> one-size-fits-all algorithm.

I'm not sure what point you are trying to make, but I believe it *is* 
possible for a solution to be found here which will keep Windows users 
happy.  I'm guessing you haven't had much practical experience with this 
problem, so probably don't see this is clearly as Windows users do.

Cheers,

Mark.