1. TortoiseHg
  2. TortoiseHg
  3. thg
Issue #3605 resolved

Workbench displaying incorrect commit message.

Jurko Gospodnetić
created an issue

In the following scenario, TortoiseHg Workbench will end up having one commit selected and displaying the commit message for a different one.

First set up the repository by doing the following:

  • Clone jurko/suds up to and including revision e3633de8e598c0afee369840bcc6aaf3294952cb.
  • You will get 1178 commits.
  • Change the phase for commit 1174 to draft, e.g. using TortoiseHg Workbench.
  • Shut down Workbench - just to get a clean startup point for reproducing the problem.

Now follow the following steps exactly, with no extra clicks:

  1. Start TortoiseHg Workbench on your local repository. Commit 1178 (HEAD) should be the initial one selected (gray line, not a blue one as if you explicitly clicked on it).
  2. Right-click on commit 1174 and import it into an MQ patch queue, which should automatically import all the later commits as well. Commit 1174 should be the one selected now (blue line).
  3. Left-click on commit 1178 (HEAD). Commit 1178 should be the one selected now (blue line).
  4. Double-left-click on commit 1174 to unapply all later patch commits. Commit 1174 should be the one selected now (blue line).
  5. Left-click on 'Working Directory' (marked as 1174+).
  6. Left-click on commit 1174. Commit 1174 should be the one selected now (blue line).
  7. Double-left-click on commit 1178 (HEAD) to apply back all the patch commits. Commit 1178 should be the one selected now (blue line).
  8. Left-click on 'Working Directory' (marked as 1178+).
  9. Left-click on commit 1178 (HEAD).

Commit 1178 should be the one selected now (blue line), but the currently displayed commit message will not belong to it, and will belong to commit 1174 instead.

When this occurs, this same 'incorrect' commit message is displayed consistently for commit 1178 as you select different commits. It reverts to normal only after restarting Workbench or marking the patches as finished.

I have seen this happen in other scenarios as well, but this is the only one so far I have been able to consistently reproduce.

There are also several other seemingly related behaviours I saw while trying to reproduce this, such as some commit message belonging to the correct commit, but not being scrolled all the way to the top of the message. This 'scrolling one' has been seen when using a commit with a longer patch description instead of 1174, and whenever it occurred I could consistently reproduce the original problem after it, but I have not taken the time to reproduce them both precisely.

My version information:

Windows 7 x64 SP1
TortoiseHg version 2.11
with Mercurial-2.9, Python-2.7.6, PyQt-4.10.3, Qt-4.8.5

Hope this helps.

Best regards, Jurko Gospodnetić

Comments (6)

  1. Jurko Gospodnetić reporter

    Bumped up the priority for this issue to major because it can cause (and has just now caused me angry) you to lose your refreshed patch commit message and have it replaced by some other commit message.

  2. Yuya Nishihara

    commit: do not restore last amend message on repository change (fixes #3605)

    On repositoryChanged, stored amend/qrefresh message is outdated. 86446536c7f8 was the workaround not to "save" the stale message, but it allowed to "load" the stale message instead.

    Steps to reproduce:

    1. two patches, only 1.diff is applied
    2. select "1.diff" -> load message to editor
    3. select wdir -> store "1.diff" message to lastCommitMsgs
    4. select "1.diff" to switch to qrefresh mode
    5. qpush up to "2.diff" -> restore "1.diff" from lastCommitMsgs (BUG)
    6. select "2.diff" -> "1.diff" message is still displayed

    → <<cset 55dee23049f8>>

  3. Jurko Gospodnetić reporter

    Thanks for looking into this! And it's great that you managed to fix it. Any chance of this getting released soon?

    It's kind of annoying not to be able to trust your version control software not to mess up your data... and this feature keeps losing me about two commit messages per day... scream

    Best regards, Jurko Gospodnetić

    P.S. This post is just me venting before I have to go back and redo a two page commit message that just got overwritten by this. cry

  4. Log in to comment