[issue2762] Eol extension when committing is totally screwed (from a user's point of view)

Sebastian Krysmanski bugs at mercurial.selenic.com
Wed Apr 13 11:11:17 UTC 2011


New submission from Sebastian Krysmanski <infomail at lordb.de>:

I've tried working the Mercurial's EOL extension but I find it hard to use.
Please correct me, if this is a totally insane expectation, but this is what
I'd expect from this extension:

"Whenever I commit or update my working copy, fix mit line endings but only
for files I tell you to (ie. files listed in .hgeol)."

Now, the "update" part seem to work (at least when the file to be updated
doesn't exist in the working copy) - but committing is totally screwed.
Sometimes it works and sometimes it doesn't. It also results in totally
unnecessary changes (from the user's point of view).

I'll provide steps for creating a small repository to demonstrate my point.
I've done this with Mercurial 1.8.2 on Windows 7 x64.

1. Create an empty repository. The eol extension should be enabled.
2. Create two files (say "windows.txt" and "linux.txt"), one with Linux file
endings (LF) and one with Windows file endings (CRLF) respectively. Add and
commit both files. After committing no line endings have changed (as
expected; that's good).
3. Create a ".hgeol" file to the root of the repository and set line ending
for both files to "native" (eg. "**.txt = native"). Add this file to the
repository.
4. Now, when committing, the eol extension should detect that the file with
Linux file endings has the wrong file endings and convert it. But it doesn't
do this. *Instead* it marks the file with the Windows line endings as
modified. The diff says all lines have changed (propably) because the line
endings have changed. However, after committing the file with Windows line
endings hasn't changed a bit. This totally confuses the user (at least myself).
5. If the previous step hadn't changed my Windows line endings file, I'd
suspect that the EOL extension only works on files that have actually
changed. So do some changes in the Linux file endings file and commit them.
(Take care that you don't mix line endings while editing.) Then commit the
changes. After that the line endings of that file are still Linux line
endings (and not Windows line endings as expected). Why the hell aren't they
converted?

What's even stranger is, when I change the line endings in ".hgeol" from
"native" to "CRLF" (which is the same on my system), suddenly all files are
modified (even the one with Windows line endings) but for all files (except
for ".hgeol" of course) "hg diff" says that there are no changes. 

Why does "native" behave differently as "CRLF"? (Btw, after commiting this
changeset the Linux file still had Linux file endings.) I even tried setting
the native line endings in the ".hgrc" file with no effect. (I tried
"eol.native" as well as "native" in the "[eol]" section. No effect.) 

Note that setting the native line endings there is described by "hg help
eol". The extension's website
(http://mercurial.selenic.com/wiki/EolExtension ) doesn't mention that but
instead says that the native line endings settings is to be placed in the
".hgeol" file (which is quite absurd IMO).

Finally, I've attached my sample repository as a starting point for the
analysis. Note that you can't use it directly as the EOL extension fixes the
line endings when updating but you can retrace the steps I did.

----------
files: EolProblem.zip
messages: 16043
nosy: manski
priority: bug
status: unread
title: Eol extension when committing is totally screwed (from a user's point of view)
topic: eol 1.8.2

____________________________________________________
Mercurial issue tracker <bugs at mercurial.selenic.com>
<http://mercurial.selenic.com/bts/issue2762>
____________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EolProblem.zip
Type: application/zip
Size: 11441 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110413/d39ebfc1/attachment.zip>


More information about the Mercurial-devel mailing list