Issue #588 resolved

Unified diff view doesn't work well with EOL extension

Sebastian Krysmanski
created an issue

The unified diff view in TortoiseHg's workbench (version 2.0.3 on Windows) doesn't work well when the EOL extension is enabled. Sometimes it says the whole file has been changed although only a few lines have changed. This happens for files for which the line endings is configured as "native" in the ".hgeol" file.

The screenshot demonstrates this. I can't post a screenshot of the whole diff here, but basically it says that the whole file has changed.

And here's what the command line "hg diff" outputs for this file:

{{{ C:\MyRepos>hg diff b1tracker\src\TrackerApp\TrackerApp.cpp diff -r 439d6b54179d b1tracker/src/TrackerApp/TrackerApp.cpp --- a/b1tracker/src/TrackerApp/TrackerApp.cpp Fri Apr 15 08:07:03 2011 +0200 +++ b/b1tracker/src/TrackerApp/TrackerApp.cpp Fri Apr 15 08:12:05 2011 +0200 @@ -974,7 +974,7 @@ if (b) mRfidEngine->setTagMode(1); else - mRfidEngine->setTagMode(); + mRfidEngine->setTagMode(0); // mRfidEngine->setTagMode(b); } } }}}

This is actually what has changed.

Just a thought: This might have something to do with the EOL extension storing files with "native" line endings as LF in the repository and OS native line endings in the working copy.

Comments (15)

  1. Steve Borho
    • changed status to open

    Indeed, our diff pane is naively comparing the repository contents against the working copy. The good news is that I believe fixing this in the one place will resolve the issue for all of thg.

  2. Steve Borho

    I'm unable to reproduce this problem. I created a test repo with eol enabled with .hgeol of

    ** = native
    native = LF

    I then created a file with DOS eoln and checked it in, then modified it. The diff was correct in both the commit tool, and in the revision details pane after checking it in.

    You'll have to attach a zip of a repo that displays the problem for me to make any progress.

  3. Sebastian Krysmanski reporter

    Sorry, I can't attach the repo since it's a private repo. I should also note that this problem only occurs sometime (ie. for some files), not for all. So I can't really tell you, how to reproduce this problem. Could you give me some instructions on how to debug TortoiseHg in case this problem occurs again?

  4. Sebastian Krysmanski reporter

    Just found out that this problem disappears (at least for a certain file) by restarting the Workbench. So it would seem that TortoiseHg retains some information/state from previous actions (commits).

  5. kiilerix

    For the case in #658 it _worked_ with 2.0.3 after it failed with 2.0.4, so it I concluded it was a different issue than this one.

    However, it is possible that it worked by coincidence because thg was restarted when I downgraded ...

  6. Steve Borho

    I would be quite surprised if thg behavior changed between 2.0.3 and 2.0.4 in this regard. My guess is that we are violating the EOL's hooks or UI data somehow.

    Can someone try modifying their ~/.hgrc file while thg is active and see if it triggers the bad behavior?

  7. Steve Borho

    I suspect this is related to configuration changes. When THG detects a configuration change, it instantiates a new ui.ui() instance and attaches it to the repo. This blows away all of the settings that the EOL extension configured (patch.eol, hooks.preupdate, encode/decode patterns). Restarting thg would recover from a properly generated UI instance.

    I think we could improve the situation with this patch (could someone verify):

    diff -r 356419639d82 tortoisehg/hgqt/
    --- a/tortoisehg/hgqt/	Tue May 17 20:05:04 2011 -0500
    +++ b/tortoisehg/hgqt/	Tue May 17 20:20:41 2011 -0500
    @@ -489,8 +489,8 @@
             def invalidateui(self):
                 'Should be called when mtime of ui files are changed'
    -            self.ui = uimod.ui()
    -            self.ui.readconfig(self.join('hgrc'))
    +            for file in self._uifiles:
    +                self.ui.readconfig(file)
                 for a in _uiprops:
                     if a in self.__dict__:
                         delattr(self, a)

    But this is still less than optimal. Many extensions just don't expect to have the repo.ui replaced (or modified) out from underneath them.

  8. 536886

    I'm seeing what a believe is a related issue with 2.11 and shelving. Since starting to use thg at about 2.4, I've had problems where shelves would re-apply to my working copy. Quitting and re-starting thg would solve the problem however since 2.11, this doesn't help either so currently I'm unable to use thg's shelve.

    I'm running on Windows 7 x64 with eol enabled and have .hgeol set to


    for our repository. Since 2.11, the issue I can reproduce is that if I modify a file in Visual Studio, then launch kdiff3 as the external diff tool from thg 2.11, then both the parent and working copy are shown as having 'DOS' line endings as expected.

    However, the following steps, for me at least, lead to the working copy ending up with UNIX line endings:

    1. After modifying the file select Repository | Shelve ...
    2. Select the chunk in the left-hand pane
    3. Select 'Delete selected chunks' from the toolbar
    4. When prompted to revert all file changes, select NO
    5. Close the shelve window

    The chunk has been reverted but thg shows the file as modified but doesn't show any changes for it. Launching kdiff3 again shows that the parent file has DOS line endings but the working copy file now has UNIX line endings so the shelve tool in deleting the chunk has changed the line endings which it shouldn't have.

    I've come across this in relation to #3600 and for me I'm wondering if it's related to #3545. If I use shelving from SourceTree 1.4.1 which sues the in-built shelve of mercurial, I don't have a problem.

  9. Log in to comment