thg issues
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues
2023-06-27T03:21:49Z
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5908
Generated patches lose binary file changes
2023-06-27T03:21:49Z
Philippe Cloutier
Generated patches lose binary file changes
TortoiseHg can generate patch files. One way to do that is to right-click on a revision, then _Export_, then _Export patch_.
Unfortunately, by default, if the changeset modifies (or removes) a binary file, the patch is incomplete, as it...
TortoiseHg can generate patch files. One way to do that is to right-click on a revision, then _Export_, then _Export patch_.
Unfortunately, by default, if the changeset modifies (or removes) a binary file, the patch is incomplete, as it just contains a line saying that the file changed, but not the change itself.
```
#!diff
diff -r rev1 -r rev2 some/file.png
Binary file some/file.png has changed
```
This occurs because TortoiseHg calls Mercurial via the CLI and uses default options. Mercurial provides the `--git` option to specify binary changes, but it is not enabled by default:
```
#!diff
diff --git a/some/file.png b/some/file.png
index rev1..rev2
GIT binary patch
literal 111
zc$@*U...
```
Whether `--git` is enabled depends on the "git format" setting (in the Diff tab), which is by default "Unspecified" (relying on Mercurial's default).
While this behavior is well documented for the `hg` command, this is less the case for TortoiseHg, which does cover this in [section 7.2. _Pitfalls_ of its manual](https://tortoisehg.readthedocs.io/en/latest/patches.html#pitfalls):
> The standard patch format cannot describe binary files, renames, copies, or permission changes. If your patch needs to record any of those things, you will need to enable git patches via:
>
> [diff]
> git=True
>
> Mercurial 1.5 improves its behavior in this regard. It will warn you when git diffs are required, or sometimes upgrade to the git format automatically. See also the diff section of the hgrc documentation.
While the last quoted paragraph seems to indicate this would be solved, this is unfortunately not the case as of TortoiseHg 6.4.2. It can happen that we don't realize that there are indeed binary files, and we end up having patches lying around that "won't work" when needed.
TortoiseHg should at least warn when it generates an imprecise patch due to a modification to a binary file, ideally offering to generate an exact patch.
I recommend to consider also changing the default behavior so that binary changes are specified. Reportedly, both hg and TortoiseHg would be happy to import Git extended diff files.
_Credits to Fernando Nájera, who [reported this](https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/3583) in a ticket on which this one is heavily based, but which somehow got lost_
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5907
Embedded diffs show "No newline at end of file" in green even without changes...
2023-06-19T21:48:12Z
Philippe Cloutier
Embedded diffs show "No newline at end of file" in green even without changes to the end
When lines close to the end of a file are changed, the embedded diff viewer can show the last line as difference context. This is what happens in the following example, since the file's pre-pre-pre-last line was modified:
![TortoiseHg_d...
When lines close to the end of a file are changed, the embedded diff viewer can show the last line as difference context. This is what happens in the following example, since the file's pre-pre-pre-last line was modified:
![TortoiseHg_diff](/uploads/d23be1e0c6b2126429c37cd4c459970a/TortoiseHg_diff.png)
TortoiseHg shows "No newline at end of file", which is not wrong, since neither the original nor the modified version end with a new line. However, that message's green color implies this has changed (i.e., that there used to be a newline at the end of the file), which is not the case. Vanilla Mercurial has it right:
![console_diff](/uploads/071c34d24418e0a34e493a0da118eb87/console_diff.png)
This affects TortoiseHg 6.4.2 on Windows 10.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5904
Update not possible => Path contains invalid component
2023-05-24T03:39:42Z
Michael Hutter
Update not possible => Path contains invalid component
I cloned a git repo (hg clone path-to-git-repo).
This usually works fine. The cloning process itself worked well. But as soon as I click on the working directory I get the following error message.
![grafik](/uploads/e632dd26184467d1529d7...
I cloned a git repo (hg clone path-to-git-repo).
This usually works fine. The cloning process itself worked well. But as soon as I click on the working directory I get the following error message.
![grafik](/uploads/e632dd26184467d1529d7382731026d9/grafik.png)
It shows a "Path contains invalid component: [UTF-BOM]"
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5900
"Copy patch" misencodes file contents
2023-06-26T15:09:36Z
Philippe Cloutier
"Copy patch" misencodes file contents
TortoiseHg offers to create a patch in the clipboard. For example, one could right-click a commit, do _Export_ -> Copy patch, then open Notepad++ and paste.
Unfortunately, as of 6.4.2, the contents of file diffs in these patches is not ...
TortoiseHg offers to create a patch in the clipboard. For example, one could right-click a commit, do _Export_ -> Copy patch, then open Notepad++ and paste.
Unfortunately, as of 6.4.2, the contents of file diffs in these patches is not properly encoded. In our case, even with UTF-8 files, non-ASCII characters in the clipboard are corrupted:
```
diff -r b37508d2d7a0 pes-sista/pes-sista-commun-webapp/pom.xml
--- a/pes-sista/pes-sista-commun-webapp/pom.xml Fri May 19 09:44:42 2023 -0400
+++ b/pes-sista/pes-sista-commun-webapp/pom.xml Fri May 19 11:47:35 2023 -0400
@@ -24,8 +24,8 @@
</dependency>
<dependency>
- <groupId>commons-httpclient</groupId>
- <artifactId>commons-httpclient</artifactId>
+ <groupId>org.apache.httpcomponents</groupId>
+ <artifactId>httpclient</artifactId>
</dependency>
<!-- Autres Dépendances -->
```
In the above, "Autres Dépendances" should read "Autres Dépendances" (with an acute accent on the "e").
This happens on Microsoft Windows 10, even after setting the server encoding to UTF-8 in repository settings. The encoding of file names and patch descriptions (log messages) is fine.
This can be worked around with the command-line Mercurial client (`hg diff`).
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5898
Load All Revisions leads to AttributeError
2023-05-19T06:15:24Z
Rudolf Michálek
Load All Revisions leads to AttributeError
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\WINDOWS
** Encoding: cp1250
** Extensions loaded: ajfhg, churn, convert, fetch, githelp, graphlog, hgk, mq, rebase, strip, tortoisehg.util.config...
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\WINDOWS
** Encoding: cp1250
** Extensions loaded: ajfhg, churn, convert, fetch, githelp, graphlog, hgk, mq, rebase, strip, tortoisehg.util.configitems, transplant, update_zpis_properties
** Python version: 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')
** Processor architecture: x64
** Qt-5.15.2 PyQt-5.15.7 QScintilla-2.13.3
Traceback (most recent call last):
File "tortoisehg\hgqt\repomodel.pyc", line 475, in timerEvent
File "tortoisehg\hgqt\graph.pyc", line 969, in build_nodes
AttributeError: module 'time' has no attribute 'clock'
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5897
Tagging a commit on different branch creates commit on current branch
2023-05-17T04:32:20Z
Philippe Cloutier
Tagging a commit on different branch creates commit on current branch
I tagged commit _x_ on branch A. When I then set to push the new commit, _y_, I was completely confused. I do not master Mercurial, but it took me several minutes to realize that TortoiseHg had created _y_ on a branch different from _x_'...
I tagged commit _x_ on branch A. When I then set to push the new commit, _y_, I was completely confused. I do not master Mercurial, but it took me several minutes to realize that TortoiseHg had created _y_ on a branch different from _x_'s, B, because my working set was on branch B.
When asked to tag a commit on a different branch, TortoiseHg should either:
1. refuse
1. create the new commit (y) on the branch of the tagged commit (x)
1. ...or ask what to do
This affects 6.4.2.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5896
Tagging - Name autocompletion is case-sensitive
2023-05-17T04:34:52Z
Philippe Cloutier
Tagging - Name autocompletion is case-sensitive
The tagging dialog's field for the tag's name (labelled Tag) helpfully offers a combo box, and autocompletion, which is very convenient. I was however confused when entering the common prefix of multiple tags offered no completion.
It t...
The tagging dialog's field for the tag's name (labelled Tag) helpfully offers a combo box, and autocompletion, which is very convenient. I was however confused when entering the common prefix of multiple tags offered no completion.
It turned out that the autocompletion is simply case-sensitive. As I was relying on completion, I entered "loi" with a lowercase "l", but existing tags were all named "Loi27...", so none matched.
The comparison with existing values should be case-insensitive.
This affects TortoiseHg 6.4.2 on Microsoft Windows 10.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5892
mercurial.error.ProgrammingError: calling `wrap` after the dirstate was inval...
2023-10-29T21:34:27Z
L Prezdente
mercurial.error.ProgrammingError: calling `wrap` after the dirstate was invalidated
The following bugreport was generated when trying to update to another branch in my project:
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\Users\Desktop
** Encoding: cp1252
** Extensions loa...
The following bugreport was generated when trying to update to another branch in my project:
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\Users\Desktop
** Encoding: cp1252
** Extensions loaded: convert, largefiles, mercurial_keyring unknown, mq, strip, tortoisehg.util.configitems
** Python version: 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')
** Processor architecture: x64
** Qt-5.15.2 PyQt-5.15.7 QScintilla-2.13.3
Traceback (most recent call last):
File "tortoisehg\hgqt\wctxcleaner.pyc", line 62, in run
File "tortoisehg\hgqt\wctxcleaner.pyc", line 37, in _checkchanged
File "hgext\largefiles\overrides.pyc", line 1380, in overridebailifchanged
File "mercurial\cmdutil.pyc", line 1133, in bailifchanged
File "mercurial\localrepo.pyc", line 244, in wrapper
File "hgext\largefiles\reposetup.pyc", line 114, in status
File "mercurial\localrepo.pyc", line 3388, in status
File "mercurial\context.pyc", line 432, in status
File "mercurial\context.pyc", line 2001, in _buildstatus
File "mercurial\context.pyc", line 1924, in _dirstatestatus
File "mercurial\context.pyc", line 1871, in _poststatusfixup
File "mercurial\dirstate.pyc", line 84, in wrap
mercurial.error.ProgrammingError: calling `wrap` after the dirstate was invalidated
```
[bugreport.txt](/uploads/492653de9cf77084915bb1b6e306126a/bugreport.txt)
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5891
Strip (extension) dialog: unclear Show Detail button
2023-04-21T22:11:57Z
Philippe Cloutier
Strip (extension) dialog: unclear Show Detail button
As reported in #5883, the dialog for Strip... (in *Modify History*, from a commit's contextual menu) contains a *Show Detail* button bottom left, which controls the display of an unlabelled textarea:
![TortoiseHg_strip](/uploads/22525d4...
As reported in #5883, the dialog for Strip... (in *Modify History*, from a commit's contextual menu) contains a *Show Detail* button bottom left, which controls the display of an unlabelled textarea:
![TortoiseHg_strip](/uploads/22525d41e95fda387a5178c2080e3f43/TortoiseHg_strip.png)
This is either a bug or at the very least confusing. I have no idea whatsoever what role plays this field.
Please either remove or label it.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5887
Got this gigantic unmanageable error popup when performing a commit
2023-04-21T08:40:53Z
php4fan
Got this gigantic unmanageable error popup when performing a commit
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 https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5887#note_293730); however, what I'm r...
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 https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5887#note_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:
1. **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.
2. 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.
3. 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.
![image](/uploads/d864698b1665de0aaecbf18c0dfee081/image.png)
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5880
Crash
2023-04-17T23:12:57Z
Michael Hutter
Crash
![grafik](/uploads/b0b02e51168beda1ee97d61181cc43de/grafik.png)
![grafik](/uploads/b0b02e51168beda1ee97d61181cc43de/grafik.png)
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5871
TortoiseHg icons not updating correctly
2023-03-13T01:57:16Z
Stead Kiger
TortoiseHg icons not updating correctly
After updating to TortoiseHg v. 6.3.2, I've noticed that the overlay icons do not update properly or are extremely slow (> 20 minutes) to update. For example, after committing a revision, the icon for the committed file will stay red in...
After updating to TortoiseHg v. 6.3.2, I've noticed that the overlay icons do not update properly or are extremely slow (> 20 minutes) to update. For example, after committing a revision, the icon for the committed file will stay red instead of changing to green. Using the update icons or refresh usually doesn't work
Another example: immediately after cloning a repository, all of the files in the new, cloned repository have red icons instead of green (except for the .hgtimestamp file--I'm using httimestamp_mod extension). Running update icons and refreshing explorer does not fix this. But if I try to use the TortoiseHg Visual Diff tool on these files, it will report "There are no file changes to view" and at that point, doing a Windows Explorer refresh will cause the overlay icon for that particular file to change from red to green.
I'm using Windows 10 Version 2004 (OS build 19041.1415).
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5866
REGRESSION: doesn't offer me option to force push when pushing new heads
2023-06-07T08:41:31Z
php4fan
REGRESSION: doesn't offer me option to force push when pushing new heads
When I do a push that results in pushing new heads, I used to get a prompt from THG that warned me that that was the case, and there was an option to continue anyway. I don't remember exactly how it was phrased, but there was an OK/Cance...
When I do a push that results in pushing new heads, I used to get a prompt from THG that warned me that that was the case, and there was an option to continue anyway. I don't remember exactly how it was phrased, but there was an OK/Cancel or Continue/Cancel choice. When choosing ok/continue/whatever-it-was, it would do a "push -f" for me.
Now, instead, I just get the error message. It's pretty clear and I just need to go and do "push -f" myself from a terminal, but it's stupid. Note that the "push -f" done from the terminal does work.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5865
DPI scaling issues on workbench
2023-06-05T03:36:52Z
Ulrich Kobsa
DPI scaling issues on workbench
TortoiseHG 6.2.3 / Windows x64:
workbench showing a lot of DPI scaling issues when moving between monitors of different DPI scaling.
start workbench on main monitor having 96 DPI (100% scaling) : everything looks fine
![workbench_96_D...
TortoiseHG 6.2.3 / Windows x64:
workbench showing a lot of DPI scaling issues when moving between monitors of different DPI scaling.
start workbench on main monitor having 96 DPI (100% scaling) : everything looks fine
![workbench_96_DPI](/uploads/28018cafc365451ac445700e1f84da2f/workbench_96_DPI.png)
now move the window to secondary monitor using 192 DPI (200% scaling)
![workbench_192_DPI](/uploads/15be174e5ed1e3f96e369a784d975d5b/workbench_192_DPI.png)
--> Fonts are getting crazy.
From Taskmanager I can see that the workbench is running per monitor aware:
![process_DPI_Awareness](/uploads/c4a7c01712d4459e8c1a3d626c3284f6/process_DPI_Awareness.png)
At least there is a workaround for it: set the application to run as system aware (on file Properties, Compatibility, High DPI settings). Then no scaling is done by application itself.
edit: just installed latest version 6.3.2. Same problem.
kind regards,
Ulrich
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5863
Immediately upon upgrading to THg 6.3.2 (Windows, x64) I get a permission den...
2023-05-04T16:41:15Z
assarbad
Immediately upon upgrading to THg 6.3.2 (Windows, x64) I get a permission denied error regarding the TortoiseHgOverlayServer
The message box reads:
```
---------------------------
Errors in 'TortoiseHgOverlayServer.exe'
---------------------------
The logfile 'C:\ProgramData\TortoiseHg\TortoiseHgOverlayServer.log' could not be opened:
[Errno 13] Permission d...
The message box reads:
```
---------------------------
Errors in 'TortoiseHgOverlayServer.exe'
---------------------------
The logfile 'C:\ProgramData\TortoiseHg\TortoiseHgOverlayServer.log' could not be opened:
[Errno 13] Permission denied: 'C:\\ProgramData\\TortoiseHg\\TortoiseHgOverlayServer.log'
---------------------------
OK
---------------------------
```
I don't know if this will be a one-time issue or points to some deeper issue. Anyway, looking at it with PowerShell we can see:
## Security descriptor of C:\ProgramData\TortoiseHg\TortoiseHgOverlayServer.log
NB: These are all inherited from `C:\ProgramData`, btw.
```
$ (Get-Acl -Path C:\ProgramData\TortoiseHg\TortoiseHgOverlayServer.log).sddl
O:BAG:S-1-5-21-1956275055-2109141404-336736917-513D:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
```
In all likelihood the file got created by an elevated process, which makes sense. Thus the file is owned by the `BUILTIN\Administrators` alias (`BA`) and the Group is set to `S-1-5-21-1956275055-2109141404-336736917-513` (`None` group, local to my machine). The ACEs are *all* inherited (`ID`):
* `O:BA` -> Owner: `BUILTIN\Administrators`
* `G:S-1-5-21-1956275055-2109141404-336736917-513` -> Group: `.\None` (this is irrelevant and was introduced for POSIX compatibility originally)
* `D:AI` (DACL, auto-inherited)
* `(A;ID;FA;;;SY)` -> Allow (inherited), File All (access) to `NT AUTHORITY\SYSTEM` (`SY`)
* `(A;ID;FA;;;BA)` -> Allow (inherited), File All (access) to `BUILTIN\Administrators` (`BA`)
* `(A;ID;0x1200a9;;;BU)` -> Allow (inherited), File Generic Read (access, == mask 0x1200a9) to `BUILTIN\Users` (`BU`)
* Hope I am getting it right, but I think that `0x1200a9 ` means:
* `FILE_READ_DATA | FILE_READ_EA` == `0x000009`
* `FILE_EXECUTE | FILE_READ_ATTRIBUTES` == `0x0000a0`
* `READ_CONTROL` == `0x020000`
* `SYNCHRONIZE` == `0x100000`
* All `or`-d together defined as **`FILE_GENERIC_READ`** in a number of Windows headers
So we need to look further up the chain ...
## Security descriptor of C:\ProgramData\TortoiseHg
NB: These are all inherited from `C:\ProgramData`, btw.
```
$ (Get-Acl -Path C:\ProgramData\TortoiseHg).sddl
O:S-1-5-21-1956275055-2109141404-336736917-1001G:S-1-5-21-1956275055-2109141404-336736917-513D:AI(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;ID;FA;;;S-1-5-21-1956275055-2109141404-336736917-1001)(A;OICIIOID;GA;;;CO)(A;OICIID;0x1200a9;;;BU)(A;CIID;DCLCRPCR;;;BU)
```
* `O:S-1-5-21-1956275055-2109141404-336736917-1001` -> Owner: local user with RID=1001 (that's my own user account)
* `G:S-1-5-21-1956275055-2109141404-336736917-513` -> Group: `.\None`
* `D:AI`
* `(A;OICIID;FA;;;SY)` -> Allow (inherited and propagating down with object inheritance [`OI`] and container inheritance [`CI`]), File All (access) to `NT AUTHORITY\SYSTEM` (`SY`) [**This folder, subfolders and files**]
* `(A;OICIID;FA;;;BA)` -> Allow (inherited and propagating down with object inheritance [`OI`] and container inheritance [`CI`]), File All (access) to `BUILTIN\Administrators` (`BA`) [**This folder, subfolders and files**]
* `(A;ID;FA;;;S-1-5-21-1956275055-2109141404-336736917-1001)` -> Allow (inherited), Full File (access) to my local user [**This folder only**]
* `(A;OICIIOID;GA;;;CO)` -> Allow (inherited and propagating down with object inheritance [`OI`] and container inheritance [`CI`], inheritance only [`IO`]), Generic All (access) to `CREATOR OWNER` (`CO`, which refers to the Owner shown above) [**Subfolders and files only**]
* `(A;OICIID;0x1200a9;;;BU)` -> Allow (inherited and propagating down with object inheritance [`OI`] and container inheritance [`CI`]), File Generic Read (access, see above) to `BUILTIN\Users` (`BU`) [**This folder, subfolders and files**]
* `(A;CIID;DCLCRPCR;;;BU)` -> Allow (inherited and propagating down with container inheritance [`CI`]), `DCLCRPCR` (see below) [**This folder and subfolders**]
* `DC` == Delete Contents (both leaf and container objects)
* `LC` == List Contents
* `RP` == Read Properties
* `CR` == All Extended Rights
## Observation
While the container object (`C:\ProgramData\TortoiseHg`) allows creation of leaf and container child objects to `CREATOR OWNER` or `BUILTIN\Administrators`, there is no other ACE that would allow writing to such a created leaf object. This would have to be set during creation from elevated context, using `LPSECURITY_ATTRIBUTES`.
## Conclusion
Thus `C:\ProgramData\TortoiseHg` should at least add an ACE of its own to the inherited ACEs, which grants `BUILTIN\Users` (`BU`) at least write, if not full, access. Local ACEs take precedence over more distant ones, which is why this would work.
**Adding** and ACE `(A;OICI;FA;;;BU)` (or `(A;OICI;FW;;;BU)`) to `C:\ProgramData\TortoiseHg` prior to any object creation inside, should fix this.
No clue how to achieve this in Python -- yet -- but I know how to do it in C# and C++ and in terms of SDDL, using PowerShell, say.
Regarding SDDL:
* https://learn.microsoft.com/en-us/windows/win32/secauthz/ace-strings
* https://itconnect.uw.edu/tools-services-support/it-systems-infrastructure/msinf/other-help/understanding-sddl-syntax/
* https://devblogs.microsoft.com/oldnewthing/20220510-00/?p=106640
* https://clan8blog.wordpress.com/2016/08/08/sddl-explained/
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5861
Crash when closing repo, asked to report by TortoiseHg bug reporter
2023-01-13T22:13:01Z
Greg Smith
Crash when closing repo, asked to report by TortoiseHg bug reporter
Opened repo directly (not via server) to modify the Description and Contact as doing this remotely does not seem to work. Opene a second repo in same way and closed the first.
```python
** Mercurial version (6.3.1). TortoiseHg version ...
Opened repo directly (not via server) to modify the Description and Contact as doing this remotely does not seem to work. Opene a second repo in same way and closed the first.
```python
** Mercurial version (6.3.1). TortoiseHg version (6.3.1+1-9c2636d208dd)
** Command:
** CWD: C:\Program Files\TortoiseHg
** Encoding: cp1252
** Extensions loaded: hggit 1.0.1 (dulwich 0.20.46), histedit, mq, rebase, strip, tortoisehg.util.configitems, uncommit
** Python version: 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
** Windows version: sys.getwindowsversion(major=6, minor=2, build=9200, platform=2, service_pack='')
** Processor architecture: x64
** Qt-5.15.2 PyQt-5.15.7 QScintilla-2.13.3
Traceback (most recent call last):
File "tortoisehg\hgqt\repotab.pyc", line 172, in closeTab
File "tortoisehg\hgqt\repotab.pyc", line 182, in _closeTabs
File "tortoisehg\hgqt\repotab.pyc", line 203, in _removeTabs
File "tortoisehg\hgqt\thgrepo.pyc", line 734, in releaseRepoAgent
KeyError: '\\\\ced-dc01\\hg\\repo\\1401\\jed2fli'
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5860
Localization broken
2023-04-04T02:51:52Z
Marcel Ellerbrok
Localization broken
Dear TortoiseHG-Support,
I am software developer on a Windows 10 system with German as natural operating system language. Nevertheless, I don't want to use TortioseHG in German, but in English. Because in a multilingual team it is commo...
Dear TortoiseHG-Support,
I am software developer on a Windows 10 system with German as natural operating system language. Nevertheless, I don't want to use TortioseHG in German, but in English. Because in a multilingual team it is common to use English expressions. To do so, I swiched the dialog language in the settings dialog to "en". As you may see in this screenshot, and everything worked fine and consistent.
![Settings](/uploads/1df3a2911186939877360f5b86480db5/Settings.png)
Recently I had to update my TortoiseHG to version 6.2.3-x64. From this moment on, the Localization of Tortoise seems very strange.
Some parts are English language, as intended. Some parts still remained in German system language. Some parts of the user interface are even mixed German AND English.
![English](/uploads/82889bdf4f543ecff0de0740ff402b29/English.png)
![German](/uploads/af5147208e6021f3657bcb8ab0bb6df5/German.png)
![Mixed](/uploads/f8d70b53c55853b8cb547a0f4276015c/Mixed.png)
Could you please investigate this issue to provide a consistent user interface in the **selected** language independend of the operationg system language?
Thanks a lot in advance!
Best regards,
Marcel Ellerbrok
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5859
Tooltips in tabs utterly broken: randomly truncated, flickering, drawing garbage
2023-03-23T19:35:12Z
php4fan
Tooltips in tabs utterly broken: randomly truncated, flickering, drawing garbage
I know this issue most likely doesn't belong to TortoiseHg but some graphics library that you use, but since I have no idea which one it is, I report it to you so that you can report it upstream.
Steps to reproduce:
- Open several rep...
I know this issue most likely doesn't belong to TortoiseHg but some graphics library that you use, but since I have no idea which one it is, I report it to you so that you can report it upstream.
Steps to reproduce:
- Open several repositories
- move the mouse cursor between tabs
Observed result:
The tooltips that show the repository path on rollover behave erratically. Sometimes they are randomly truncated. Sometimes the animation (btw, there's no need to animate them, it's just stupid) is broken, stretching or squeezing the characters to absurd sizes. Sometimes they flicker. Sometimes random portions look like they have been cut and pasted elsewhere. Sometimes they generate shadows that don't match. Sometimes pieces of the tooltips that are already gone remain there randomly blinking. It's a *****show, basically.
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5854
TortoiseHG isn't charset-agnostic anymore?
2022-12-17T16:15:04Z
Lazy Badger
TortoiseHG isn't charset-agnostic anymore?
Old issue with full 8-bit texts and different charsets for GUI and CLI (solvable earlier - in HG 4-5 - with proper `chcp`)
Mercurial
```
hg --version -v --debug
pager is unavailable with py2exe packaging
Mercurial Distributed SCM (vers...
Old issue with full 8-bit texts and different charsets for GUI and CLI (solvable earlier - in HG 4-5 - with proper `chcp`)
Mercurial
```
hg --version -v --debug
pager is unavailable with py2exe packaging
Mercurial Distributed SCM (version 6.2.3)
(see https://mercurial-scm.org for more information)
Copyright (C) 2005-2022 Olivia Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Enabled extensions:
convert internal
hggit external 1.0.0 (dulwich 0.20.46)
histedit internal
rebase internal
strip internal
```
Windows
```
ver
Microsoft Windows [Version 10.0.19045.2364]
```
Objects affected:
* 8bit texts of commit-messages
* 8bit filenames in diffs
* 8bit as diff-content
I haven't for now repos with 8bit filenames, but... The nature and manifestation of the effects of paragraphs 1 and 2 are the same
Steps to reproduce:
1. Make commit with 8bit message in GUI (THG, cp1251)
1. Try `hg log` in CLI (any, cp866 by default)
2. Switch codepage, repeat `hg log`
3. Get the same output (unreadable) both times, while expect it only on step 2
```log
hg log -r ("5 or 11") -T compact | bat -p
5 8f2cca1130c2 2020-01-23 12:45 +0500 lazybadger
╚ёяЁртыхэшх чруюыютър, ЄхёЄ
11 96d6f08eeddf 2020-03-15 15:55 +0500 lazybadger
╬ЇюЁьыхэ√ чруюыютъш тёхї ёЄЁрэшЎ kick-start, шёяЁртыхэ√ юяхўрЄъш
chcp
Active code page: 866
chcp 1251
Active code page: 1251
hg log -r ("5 or 11") -T compact | bat -p
5 8f2cca1130c2 2020-01-23 12:45 +0500 lazybadger
╚ёяЁртыхэшх чруюыютър, ЄхёЄ
11 96d6f08eeddf 2020-03-15 15:55 +0500 lazybadger
╬ЇюЁьыхэ√ чруюыютъш тёхї ёЄЁрэшЎ kick-start, шёяЁртыхэ√ юяхўрЄъш
```
(Piping to bat added only for readability of chars, it doesn't perform any decoding, because plain log with my font produce just totally useless `����������� ���������, ����`)
Using decoder on bat's output, as restored my texts as "source encoding: WINDOWS-1251 displayed as: CP866" (which is definitely wrong for step 3 from "Steps")
Concerning item 3 from "Objects affected" list: I see readable output only for UTF8-encoded text, not for (common) cp 1251 windows-encoding, which is **A Big Headache** in some (non-coding) areas and cases, but less critical than every-day case for log
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5853
SetuptoolsDeprecationWarning: setup.py install is deprecated
2023-01-05T16:54:08Z
CharlieC
SetuptoolsDeprecationWarning: setup.py install is deprecated
I'm trying to update the MacPorts port to 6.3.1 but am hitting a problem that the build command is now deprecated:
```
Executing: cd "/opt/local/var/macports/build/_Users_charlieclark_temp_macports-ports_devel_tortoisehg/tortoisehg/wor...
I'm trying to update the MacPorts port to 6.3.1 but am hitting a problem that the build command is now deprecated:
```
Executing: cd "/opt/local/var/macports/build/_Users_charlieclark_temp_macports-ports_devel_tortoisehg/tortoisehg/work/thg-6.3.1" && /opt/local/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10 setup.py --no-user-cfg build -j1
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
warnings.warn()
```
I'm not that sure where I should be digging in order to patch this. I _could_ use a different Python version but if this is down to setuptools then the error is likely to persist.