A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-August/090973.html below:

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

[Python-Dev] PEP 385: the eol-type issue [Python-Dev] PEP 385: the eol-type issueBen Finney ben+python at benfinney.id.au
Wed Aug 5 07:56:16 CEST 2009
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?

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

-- 
 \          “Our products just aren't engineered for security.” —Brian |
  `\             Valentine, senior vice-president of Microsoft Windows |
_o__)                                                      development |
Ben Finney

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4