[MERGE] integrated EOL conversion support

[Ian Clatworthy]

Jonathan Gossage wrote:
> Ian Clatworthy wrote:
>> John Arbash Meinel wrote:

>>> I honestly think people care more about the value they get when they are
>>> working on the file, because it matters what other tools are going to do
>>> with it.

>> And I understand your point. The problem is that some/many projects will
>> define project-specific rules and check them in to their branch or
>> version-control them in a separate, shared location that developers will
>> be told to point their path to. The moment I deliver custom rules - rules
>> defined somewhere else besides each user's bazaar.conf file, then the
>> emphasis *must* be first-and-foremost on what get's *committed*, not what
>> individual users would like in their working tree. I also
>> feel that native-in-the-tree is the most sensible default so specifying
>> that is a bit redundant.

> Here is a user perspective on the CR/LF mess we all have to deal with.
> If you do things right, what is important that the document arrive in
> the user's workspace with the line termination needed for the particular
> task at a given time. Generally, the user is going to want the platform
> format for line endings but in a heterogeneous environment there will be
> times and tools where the user will need to be able to specify precisely
> what is required.

Thanks for the feedback Jonathan. I think you're confirming what John is
saying: people mentally think about the working tree format as their
priority even if the collective "project" cares more about what's stored
in the VCS repository.

Several people, John included from memory, have suggested using compound
names like native-lf, crlf-crlf, etc. where one part is the WT format and
another part is the repo format. If we do this and put the WT format first,
we get:

* native-lf   (instead of lf)
* native-crlf (instead of crlf)
* lf-lf       (instead of lf-always)
* crcf-crlf   (instead of crlf-always)
* exact.

Would those names be better and reduce the potential for confusion?

Ian C.