[Python-Dev] PEP 385: the eol-type issue (original) (raw)
Ben Finney ben+python at benfinney.id.au
Wed Aug 5 08:50:05 CEST 2009
- Previous message: [Python-Dev] PEP 385: the eol-type issue
- Next message: [Python-Dev] PEP 385: the eol-type issue
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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 processing tools.
these differences matter in many concrete ways to the tools that process text, so the differences need to be preserved, or explicitly transformed.
distributed VCS has the job of preserving data as present on the filesystem, including whatever line-ending convention is present in a file.
distributed VCS has the job of managing data exchange between users, presenting differences in a way that allows easy inspection and merging.
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 one-size-fits-all algorithm.
-- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | o_) | Ben Finney
- Previous message: [Python-Dev] PEP 385: the eol-type issue
- Next message: [Python-Dev] PEP 385: the eol-type issue
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]