Line ending translation extension

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > So clearly, we need a maintained version first.

No, we need something that comes close to working for us, first.  Once
we've got that, we can hope to get the Mercurial folks to maintain it.
But they're going to want a strong testimonial from us that it is TRT
and deserves TOOWTDI status in Mercurial.  If we can give them that, I
think they "should" accept it, and probably will.

But right now, there's a big problem in selling a new extension to the
Mercurial maintainers: In terms of basic functionality, win32text does
everything hg-eol/eol.py does.  It also provides implementations of
precommit (resp. prepush) hooks to prevent committing (resp. pushing)
files with "wrong" EOLs, which is something else you asked for (in
some form).

So, what do we want to add/improve?

(0) Versioned, per-file configuration of eol checking/conversion.
    This is the big one.  It's critical to getting the initial
    checkout to "just work" for Windows people.

    That should be easy: merge with code from hg-eol.

(1) UI is complex and ugly, in ways that aren't useful to us.  For the
    base case, we'd like to just ask the new user to do

    [extensions]
    hgext.hg-eol =

    and it should just work.  hg-eol accomplishes this, too, pretty
    much.

(2) hg-eol's filters handle files with various mixtures of newline
    conventions.  I don't know if this really matters.

(3) The forbid* validators are repo-wide, not per-file, as far as I
    can see.  It's also got the sense of the test wrong from our point
    of view.  Instead of requiring an appropriate EOL, it forbids the
    platform EOL.

(4) I think we also want an EOL-consistency-across-commits check.

    A related issue is that the win32text extension's forbidcrlf hook
    tries pretty hard to allow a "wrong" commit if it's followed by a
    commit to fix the EOLs.  I don't know if we want that.  We might
    want a stricter forbid hook, and ask developers to rebase to get
    rid of the offending versions.

(5) Do we want to do something about hg add?  Ie, make it ask (perhaps
    only about files in certain directories, etc) if an entry should
    be added to .hgeol?

(6) What about hg mv and hg cp?  Should the eol attribute "follow"
    files that are renamed or copied?

(7) How about true binaries (JPEGs and the like)?  In the current
    scheme I guess marking them as "LF" works, but maybe there should
    be an alias "binary" for LF?

(8) Documentation is hard to understand.

 > Ok, then install the proposed extension, add an .hgeol file, and set
 > your preferred eol-style to CRLF. Then see whether it works.

OK, done.  But "it works" means what?  I don't have a spec except
"what svn does" and I don't know what that is, and XEmacs will show me
a text file no matter what hg does.  Hey, it works!<wink>

More specifically, what is the sensible behavior if I do that in an
existing LF checkout?  Should it convert the specified files to CRLF?
If so, when?  Or should it just warn that it expects CRLF files but
got LF files, and I should check out again?  What Do Windows Users Want?

 > Ah, ok. That may well be. I don't know Mercurial good enough to tell
 > what commands should be modified in what way, and whether it is at
 > all possible to provide the feature by means of an extension.

Well, Python being a consenting-adults monkey-patchable language, I'm
sure it's possible.  Whether it's possible to get Mercurial to
maintain it, that is another question.