The bug that caused this error to happen is most likely in an extension and I'll report it there probably a bug in TortoiseHg too (see #5887 (comment 293730)); however, what I'm reporting here is the way this error is presented.
There are a few things wrong in how the error is handled by THG and presented to the user:
The window is huge. In my case the OK button was barely clickable; on a smaller display than mine it could very well have been completely outside of the screen and unreachable. Every window should always have a limited size constrained by the size of the screen, and if the contents don't fit then it should have a scrollbar.
The window could not be resized. EVERY window should always be resizable no matter what. And that remains true even once point 1 is fixed. If the popup had been of a reasonable size and scrollable, I may even want to increase the size for that matter, in order to read the contents without scrolling too much.
The bold part of the error message is unreadable and too long. You shouldn't put an entire stack trace into that part of the error message. That is supposed to be a header, which should be limited in length, and readable and understandable to the end user. A backtrace belongs to the "body" of the message, below, not in bold and with line breaks.
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Also, after the error, the commit was saved, but the commit message was still in the textarea in the commit panel or widget or whatever it's called.
Usually, after committing, the commit message is removed from there.
Yeah, this is terrible and I've hit it a few times myself. It seems limited to commands run through commandserver, and I have no idea where the code that handles that is. The commit message likely stayed because the exception occurred after the commit in commandserver, but before thg finished the post-processing.
Do you happen to have the largefiles extension enabled by any chance?
Actually the error itself does not seem to be caused by mercurial-extension_utils at all. After disabling that and mercurial_keyring, the exact same error shows up, only this time Mercurial blames it on some other random "possibly-broken third party extension".
Do you happen to have the largefiles extension enabled by any chance?
File "/usr/lib/python3.10/site-packages/tortoisehg/util/partialcommit.py", line 46, in partialcommit repo.dirstate.set_possibly_dirty(f) File "/usr/lib/python3.10/site-packages/mercurial/dirstate.py", line 85, in wrap return func(self, *args, **kwargs) File "/usr/lib/python3.10/site-packages/mercurial/dirstate.py", line 131, in wrap raise error.ProgrammingError(msg)mercurial.error.ProgrammingError: calling `set_possibly_dirty` outside of a changing_files or running_status contextcmdserver: process exited unexpectedly with code 1
it looks like the error itself is actually a bug in TortoiseHg.
If I interpret the trace correctly:
Mercurial complains that someone is "calling set_possibly_dirty outside of ..." ...outside of where it's supposed to be called
that call is being made by `/.../tortoisehg/util/partialcommit.py", which seems to belong to TortoiseHg.
Do you happen to have the largefiles extension enabled by any chance?
I don't think so.
hg version -v in that repo will tell you.
it looks like the error itself is actually a bug in TortoiseHg.
Possibly, but this module was fixed already for the core API change in 6.4. I've seen similar errors around the API change when the largefiles extension is enabled (not necessarily used), like in #5880 (closed).
If you're able to reproduce this on demand, can you paste the contents of the log window with the stacktrace? The messagebox is indecipherable, as you pointed out. Also, can you describe the repo state at the time of the error? Obviously you're committing, but are some files selected and others not, some hunks in some files selected and some not, all modified files, or adds/removes/etc... that kind of thing. Basically, I need enough info to reproduce this locally.
Which version of thg do you use ? the line number in your traceback does not match the latest one, and the error is mentionning that your thg version is only supporting up to Mercurial 6.2 (while you run Mercurial 6.4)
I think it's the latest available packaged version in Manjaro's AUR, but I'm unsure and I'll explain.
Initially I was using the Manjaro AUR package (which is still installed on my system and up-to-date and is now version 6.2.2.20125-1).
Then 2 years ago the infamous issue 5602 appeared, and after a few months I found a workaround for it. So I cloned the TortoiseHg repository from here, applied that patch, and started using that version with my patch.
By the time I reported this bug I I was still using the same version but I had forgot that. I thought I was using the packaged version and that it had got updated to whatever the latest package version is.
The way I run the repository-cloned (and patched) version is:
I have it in a given folder
I created a symlink ~/.local/bin/thg_s which points to /path/to/cloned/repo/thg/thg
I created a .desktop file for it and pinned it to the task manager and that's what I usually run
So now (which is yesterday) I thought: probably Mercurial got updated but I'm still using the 2-year-old version of THG and the mismatch causes the error, so let's try and update it.
So now I updated the repository version to the latest commit and re-applied my patch for issue 5602, and tried it, and the set_possibly_dirty bug persists. One thing I noticed though is that the paths of files in the backtrace reference system-wide-install files. So maybe, even though (and assuming) I run the thg executable from the cloned up-to-date repository, it stills runs libraries from the system?
So I tried running what I believe should be the system-installed version (from the AUR), and I still get the error.
But the most confusing thing is that, no matter which binary I try to run, the version that shows up in Help -> About TortoiseHg is always the same, that is 6.2.2+2-b619f172c9da.
To clarify, there are 4 ways I can run TortoiseHg on my system:
from the Application Launcher or Task Manager, using my own .desktop file which points to ~/.local/bin/thg_s (s for "source") which in turn is a symlink to the thg binary in the cloned repository
from a terminal, running thg_s which points to the binary in the cloned repository
from the Application Launcher or Task Manager, using the .desktop file that came with the system packages (which actually I seem to remember I had to take and copy to the appropriate directory for the system to find it)
from a terminal, running thg, which is /usr/bin/thg, which is not a symlink and is what the system packages installed.
I would expect 1 and 2 to run the cloned repository version, and 3 and 4 to run the system package one.
However, as I said, no matter which one I run, "About TortoiseHg" always says the same thing. Which is confusing.
Also, in all cases I don't get issue 5602, which seems to suggest that I'm always running the repository version (which is extremely confusing), unless issue 5602 has been fixed in the meantime.
To the fact that, apparently, even while running the repository version, system-installed libraries are still used, I do have a hypothesis. Maybe, even though I am running Thg from the repository, when I perform a commit, the Thg GUI launches a hg command, as if it was run from a terminal, and that in turn somehow triggers thg stuff that is still run as if run in a terminal, i.e. using the system-wide installed version.
That still doesn't explain why Help/About always says the same version (which seems to be one from a few months ago, so probably the AUR one). MAYBE, the thing that shows the About also runs from a library, and MAYBE, even when running the binary from the repository clone, the libraries being used are still the system-wide ones.
And none of this explains how I don't hit issue 5602 regardless of which binary I run.
If you're able to reproduce this on demand, can you paste the contents of the log window with the stacktrace?
Sure, attached below.
Basically, I need enough info to reproduce this locally.
To reproduce at will here's what I do:
edit a file in a repository, making changes at two separate places distant enough.
in THG, select only one of the two changes,
enter a commit message and commit
% hg commit --verbose --message=sdfvdv --user "Matteo <matteosistisette@gmail.com>" --partials /tmp/thg-patch-r35ogy81 -- forum/XML/product-zh_noavatar.xmlpatching file forum/XML/product-zh_noavatar.xmlcommitting files:forum/XML/product-zh_noavatar.xmlcommitting manifestcommitting changelogcommitted changeset 10:baac3658f573** Unknown exception encountered with possibly-broken third-party extension "tortoisehg.util.hgcommands" (version N/A)** which supports versions 6.2 of Mercurial.** Please disable "tortoisehg.util.hgcommands" and try your action again.** If that fixes the bug please report it to the extension author.** Python 3.10.10 (main, Mar 5 2023, 22:26:53) [GCC 12.2.1 20230201]** Mercurial Distributed SCM (version 6.4)** Extensions loaded: tortoisehg.util.hgcommands, tortoisehg.util.hgdispatch, tortoisehg.util.partialcommit, tortoisehg.util.pipeui** ProgrammingError: calling `set_possibly_dirty` outside of a changing_files or running_status context** Unknown exception encountered with possibly-broken third-party extension "tortoisehg.util.hgcommands" (version N/A)** which supports versions 6.2 of Mercurial.** Please disable "tortoisehg.util.hgcommands" and try your action again.** If that fixes the bug please report it to the extension author.** Python 3.10.10 (main, Mar 5 2023, 22:26:53) [GCC 12.2.1 20230201]** Mercurial Distributed SCM (version 6.4)** Extensions loaded: tortoisehg.util.hgcommands, tortoisehg.util.hgdispatch, tortoisehg.util.partialcommit, tortoisehg.util.pipeui** ProgrammingError: calling `set_possibly_dirty` outside of a changing_files or running_status contextTraceback (most recent call last): File "/usr/bin/hg", line 59, in <module> dispatch.run() File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 143, in run status = dispatch(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 232, in dispatch status = _rundispatch(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 276, in _rundispatch ret = _runcatch(req) or 0 File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 451, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 461, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python3.10/site-packages/mercurial/scmutil.py", line 153, in callcatch return func() File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 441, in _runcatchfunc return _dispatch(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1266, in _dispatch return runcommand( File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 899, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1278, in _runcommand return cmdfunc() File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1264, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python3.10/site-packages/mercurial/util.py", line 1881, in check return func(*args, **kwargs) File "/usr/lib/python3.10/site-packages/mercurial/commands.py", line 6655, in serve return server.runservice(opts, initfn=service.init, runfn=service.run) File "/usr/lib/python3.10/site-packages/mercurial/server.py", line 166, in runservice return runfn() File "/usr/lib/python3.10/site-packages/mercurial/commandserver.py", line 461, in run return sv.serve() File "/usr/lib/python3.10/site-packages/mercurial/commandserver.py", line 395, in serve while self.serveone(): File "/usr/lib/python3.10/site-packages/mercurial/commandserver.py", line 369, in serveone handler(self) File "/usr/lib/python3.10/site-packages/mercurial/commandserver.py", line 350, in runcommand ret = self._dispatchcommand(req) & 255 File "/usr/lib/python3.10/site-packages/mercurial/commandserver.py", line 289, in _dispatchcommand return dispatch.dispatch(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 232, in dispatch status = _rundispatch(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 276, in _rundispatch ret = _runcatch(req) or 0 File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 451, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 461, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python3.10/site-packages/mercurial/scmutil.py", line 153, in callcatch return func() File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 441, in _runcatchfunc return _dispatch(req) File "/usr/lib/python3.10/site-packages/tortoisehg/util/hgdispatch.py", line 23, in _dispatch return orig(req) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1266, in _dispatch return runcommand( File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 899, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1278, in _runcommand return cmdfunc() File "/usr/lib/python3.10/site-packages/mercurial/dispatch.py", line 1264, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python3.10/site-packages/mercurial/util.py", line 1881, in check return func(*args, **kwargs) File "/usr/lib/python3.10/site-packages/mercurial/util.py", line 1881, in check return func(*args, **kwargs) File "/usr/lib/python3.10/site-packages/tortoisehg/util/partialcommit.py", line 46, in partialcommit repo.dirstate.set_possibly_dirty(f) File "/usr/lib/python3.10/site-packages/mercurial/dirstate.py", line 85, in wrap return func(self, *args, **kwargs) File "/usr/lib/python3.10/site-packages/mercurial/dirstate.py", line 131, in wrap raise error.ProgrammingError(msg)mercurial.error.ProgrammingError: calling `set_possibly_dirty` outside of a changing_files or running_status contextcmdserver: process exited unexpectedly with code 1ZH_No_Avatar%
Mercurial Distributed SCM (version 6.4)(see https://mercurial-scm.org for more information)Copyright (C) 2005-2023 Olivia Mackall and othersThis is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Enabled extensions:
One thing I noticed though is that the paths of files in the backtrace reference system-wide-install files.
But the most confusing thing is that, no matter which binary I try to run, the version that shows up in Help -> About TortoiseHg is always the same, that is 6.2.2+2-b619f172c9da.
OK, this is a problem- thg is only backward compatible, not forward compatible. There was an API change in hg 6.4 that requires you to have thg 6.4 in order to handle it.
I have no idea why it's reading system installed files if you're running it from source. Maybe you have PYTHONPATH set somewhere? For me, python3 thg --nofork at the root of the thg repo will run the local source.
unless issue 5602 has been fixed in the meantime.
There was another bug handling the diff options that's been fixed in the last ~4 months, but I don't think that would make it honor whitespace.
Maybe, even though I am running Thg from the repository, when I perform a commit, the Thg GUI launches a hg command, as if it was run from a terminal, and that in turn somehow triggers thg stuff that is still run as if run in a terminal, i.e. using the system-wide installed version.
Yes, that's the commandserver process. I'd expect the thg extensions to be picked up from the local repo though, which is all the commandserver process uses. As of last night, the stable branch now has code to report the thg version in the extensions loaded by command server. So if you update your thg source and try again, you'll either see the versions in the crash (and know you're using running the latest code), or you won't and you'll know commandserver is loading the extensions from elsewhere.
Any reason to not just uninstall the AUR version, and simplify all of this?