EOL extension

Martin Geisler mg at lazybytes.net
Tue Dec 1 17:20:39 CST 2009


Mark Hammond <mhammond at skippinet.com.au> writes:

> In that first response (which I am surprised managed to stretch to so
> many emails before being directly acknowledged)

Well, I think nobody acknowledged the mail because (as far as I know)
we've infact always been able to handle that case mentioned. See below.

> I was looking to avoid any configuration being necessary when a file
> with an 'unknown' extension is added. This should prevent files being
> accidentally introduced with \r\n line endings, and potentially edited
> on non-windows platforms before someone notices and needs to make a
> "correction" checkin which appears to touch every line in the file.

The old win32text lets you do this to mark all non-binary files as
native:

  [extensions]
  hgext.win32text =

  [encode]
  ** = cleverencode:

  [decode]
  ** = cleverdecode:

That is the per-user configuration and it's takes straight from the
documentation. The new eol extension will let you do the same by adding

  [patterns]
  ** = native

to .hgeol in the repository. Is that not what you're asking for or am I
being very dense? :-)

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091202/b6cbf037/attachment.pgp>


More information about the Mercurial-devel mailing list