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

Mark Hammond skippy.hammond at gmail.com
Wed Aug 5 08:08:43 CEST 2009

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. I'm guessing I would be forced to make a number of
>> whitespace-only checkins to normalize the line-endings before it could
>> merge - and these checkins would then be in the history forever.
> What is wrong with that? I mean, if that is the actual sequence of
> events, why should the history not reflect that?

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.

>> Either way, the situation doesn't seem good.
> I see this assertion made often, so I'm not saying you are necessarily
> wrong to make it. I just don't see a justification for making it (and,
> without justification, I would say it *is* wrong to make it).

*shrug* - in my opinion, the fact the developer is faced with that 
hurdle in their workflow is justification enough to say that developer's 
situation "doesn't seem good" and should have been prevented from 
happening by the tool much earlier than proposed.


More information about the Python-Dev mailing list