[Python-Dev] hgeol extension (Was: Mercurial migration: help needed)
brett at python.org
Sat Sep 5 22:20:14 CEST 2009
On Sat, Sep 5, 2009 at 07:18, "Martin v. Löwis"<martin at v.loewis.de> wrote:
>> 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
> 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.
> **.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
> 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
> - 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).
More information about the Python-Dev