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

["Martin v. Löwis"]

>> Not as Mercurial, no. As Python, we can certainly expect that all of our
>> contributors have read the developer FAQ, and set up their systems
>> accordingly. If all else fails, we can revoke commit access (or is
>> it "push access"?) if some committer doesn't get the configuration
>> right. We would, of course, prefer if it was very easy to get the
>> configuration right, so that problems don't occur in the first place.
> 
> There will also be non-committers who forge changesets that you want
> to be able to push directly to the Python repositories.

They will also have to follow the policies we set up. If they refuse to
do that, we refuse to accept their changes. It's very simple, and
contributors have learned very quickly what the policies were (after
they were explained to them).

Whether that means that they have to fix their changesets, or that they
have to redo them, practice will show.

>> If the client machines were the primary line of defense, Windows users
>> were treated equally: they would make as few mistakes as Unix users,
>> because the hooks do what they want correctly.
> 
> Similarly, if Python kept its .py files in \r\n line endings by
> default instead of \n endings, Unix-like users would be more prone to
> mistake, so by keeping the .py files in \n-format, so Python is making
> Windows users second-rate by keeping the line endings in \n format. To
> cope with that, hg needs to do extra work on the client side.

I think you still miss the point. *If* hg does the extra work, *then*
Windows users are *not* second-class citizens anymore. They *only*
consider themselves second-class if they have to do additional *manual*
work (*).

Regards,
Martin

(*) They may also consider themselves second-class if they have to
install additional software, so hopefully, the necessary extra code for
hg will become part of the regular Mercurial distribution at some point.