On Sat, Sep 5, 2009 at 07:18, "Martin v. Löwis"
Can anyone (re-) post the specification of the proposed extension, to the level that it is currently defined?
For reference, here are the original specification, mine and Martin Geisler's:
http://mail.python.org/pipermail/python-dev/2009-August/090984.html http://mail.python.org/pipermail/python-dev/2009-August/091453.html
Here is my attempt at summarizing it:
- name of versioned configuration file (in root of tree): .hgeol - names of conversion modes: native, LF, CRLF In the configuration file, there is a section [patterns] which maps file name patterns to conversion modes, e.g.
[patterns] **.txt = native **.py = native **.dsp = CRLF **.bat = CRLF Tools/bgen/README = native Lib/email/test/data/msg_26.txt = CRLF
- Martin Geisler also proposes that there is a section [repository] native = <conversionmode> I personally feel YAGNI; it should only support LF (adding such a feature later may be considered)
Do you mean what native is in the repo or what it should be considered on the user's machine? If it's the former then I actually like it as it means a clone doesn't need to do anything special when 'native' matches what is expected in the repo while a commit still does its EOL validation. I still think we need to have a server-side block which rejects commits that messes up the line-endings so people can fix them. Shouldn't mess up 'blame' as the messed up line-endings should only be from their edits. Otherwise it's just like when Tim used to run reindent.py over the entire repo on occasion. And as mentioned in another email by Paul, it would be nice to let the user specify what they want 'native' to be on their machine if they happen to be a Windows user who prefers LF.
Open issues: - name of extension
StupidLineEndings =)
- what should happen if the file on disk doesn't have the "expected" line endings, or mixed line endings? E.g. a file declared as native "should" have CRLF on Windows - what if it doesn't, on commit? My proposal: do what svn does (whatever that is).
Or refuse the commit with a message and tell the user to fix it (if svn doesn't happen to do that). -Brett