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