[Python-Dev] PEP 385: the eol-type issue
ben+python at benfinney.id.au
Wed Aug 5 08:50:05 CEST 2009
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
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.
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).
> *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.
AIUI, this is a combination of several things:
* different OSen have incompatible, entrenched conventions for
line-ending that is embodied in the default output of their text
* these differences matter in many concrete ways to the tools that
process text, so the differences need to be preserved, or explicitly
* distributed VCS has the job of preserving data as present on the
filesystem, including whatever line-ending convention is present in a
* distributed VCS has the job of managing data exchange between users,
presenting differences in a way that allows easy inspection and
* humans want to pretend that these incompatibilities don't exist, and
want “end of line” to be an automatically-handled abstraction.
It's not a simple thing to solve, and many clever people have tried over
the decades. The fact that a centralised VCS can put the problem aside
by requiring an explicit, single decision in the repository, is no help
when addressing the constraints of a distributed VCS.
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
\ “All progress has resulted from people who took unpopular |
`\ positions.” —Adlai Stevenson |
More information about the Python-Dev