thg issueshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues2023-08-17T17:43:14Zhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5937TortoiseHg Shelve (shelve tool) appears undocumented from built-in help, desp...2023-08-17T17:43:14ZPhilippe CloutierTortoiseHg Shelve (shelve tool) appears undocumented from built-in help, despite 5.8. ShelveTortoiseHg Shelve does not directly offer documentation, so users looking for some will most likely go back to the Workbench (main window) and invoke the _Help_ item from the _Help_ menu. Unfortunately, this opens a webpage which only co...TortoiseHg Shelve does not directly offer documentation, so users looking for some will most likely go back to the Workbench (main window) and invoke the _Help_ item from the _Help_ menu. Unfortunately, this opens a webpage which only contains section `5.4. Workbench` of the documentation, which says nothing about the shelve tool.
Yet, it is documented, in section `5.8. Shelve`.
I do not know TortoiseHg enough to recommend a solution, but moving 5.8. inside 5.4. might be an option.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5936Documentation: Unclear "DOS eoln text files" in 5.8. Shelve section's note2023-08-19T04:25:56ZPhilippe CloutierDocumentation: Unclear "DOS eoln text files" in 5.8. Shelve section's note[Section 5.8. of the documentation](https://tortoisehg.readthedocs.io/en/latest/shelve.html#module-shelve.dialog) contains the following note:
> We highly recommend setting the patch eol configuration to auto if you use the shelve tool w...[Section 5.8. of the documentation](https://tortoisehg.readthedocs.io/en/latest/shelve.html#module-shelve.dialog) contains the following note:
> We highly recommend setting the patch eol configuration to auto if you use the shelve tool with DOS eoln text files.
It is very unclear what "DOS eoln text files" means. I'm a senior software developer and don't remember seeing the word "eoln" before. Based on my searches, I assume "eoln" refers to a function found in some old libraries, which abbreviates "end of line". "End of line" is generally abbreviated "EOL" or "EoL". If "DOS eoln text files" does mean DOS end of line text files, I assume this means text files using the sequence of control characters which the DOS family of operating systems uses to represent/store a newline. If that's correct, that would mean text files where newlines are represented by [CR+LF](https://en.wikipedia.org/wiki/Newline#Representation).
If that's correct, I suggest replacing with:
> We highly recommend setting the patch eol configuration to auto if you use the shelve tool with text files where newlines are represented by the CR+LF sequence (a carriage return followed by a line feed), such as those created by Microsoft operating systems.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5925Unclear multiple heads (branch/description columns do not distinguish remote/...2023-08-19T11:54:03ZPhilippe CloutierUnclear multiple heads (branch/description columns do not distinguish remote/local)Mercurial allows a branch to have multiple heads. When a shared branch (let's call it `default`) is worked on by multiple people, at some point one will pull changes to `default` made by other, and the local repository will end up contai...Mercurial allows a branch to have multiple heads. When a shared branch (let's call it `default`) is worked on by multiple people, at some point one will pull changes to `default` made by other, and the local repository will end up containing 2 heads for `default` (the local one and the remote one).
This situation, while common, is "irregular" and should be resolved, yet TortoiseHg does not show this very clearly. The _Graph_ column does show distinct lines, but they use the same color and the _Branch_ and _Description_ columns do not clearly indicate when a head is duplicated. When a branch has several heads, the _Branch_ column just contains the name and the _Description_ column merely prepends a green tag with the branch's name for each head.
It would greatly reduce confusion to indicate such situations clearly. Either display a warning somewhere (a bar at the top), or display some kind of warning on the rows of conflicting heads. For example, the green tag in the _Description_ column could become red, orange or yellow. Or, it could contain an asterisk or/and some number (let's say "1" for the local branch and "2" for the remote branch).https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5924Unable to apply MQ patches via double click in main view.2023-08-14T05:52:19Zdflachsqi2Unable to apply MQ patches via double click in main view.I was unable to find mention of this issue, though it may be due to not knowing the correct terms. I am unable to apply an mq patch by double clicking it in the main viewport. Doing so generates a popup titled 'Unable to find changeset" ...I was unable to find mention of this issue, though it may be due to not knowing the correct terms. I am unable to apply an mq patch by double clicking it in the main viewport. Doing so generates a popup titled 'Unable to find changeset" with the message "You likely need to refresh this application". Right clicking the patch and selecting the "Apply Patch" option works correctly. Double clicking an already applied patch correctly un-applies it.
I am running windows 10 build 19044 and
TortoiseHg
version 6.4.5
with Mercurial-6.4.5, Python-3.9.13, PyQt-5.15.7, Qt-5.15.2
![image](/uploads/d501618d238c31ab4cb64a9f7f85fc43/image.png)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5923win7 not support2023-11-06T16:06:10ZPTM nonewin7 not supportWhen i start workbench, i see message and workbench dont start.
second question: how i can change cp1251? bcause tortoisehg cant clone structure ( name to long_)
```python
** Mercurial version (6.4.5). TortoiseHg version (6.4.5)
** Com...When i start workbench, i see message and workbench dont start.
second question: how i can change cp1251? bcause tortoisehg cant clone structure ( name to long_)
```python
** Mercurial version (6.4.5). TortoiseHg version (6.4.5)
** Command: --nofork workbench
** CWD: C:\Users\PTM\Desktop\ьз3
** Encoding: cp1251
** Extensions loaded: 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=1, build=7601, platform=2, service_pack='Service Pack 1')
** Processor architecture: x64
** Qt-5.15.2 PyQt-5.15.7 QScintilla-2.13.3
Traceback (most recent call last):
File "tortoisehg\hgqt\run.pyc", line 143, in dispatch
File "tortoisehg\hgqt\run.pyc", line 352, in _runcatch
File "tortoisehg\hgqt\run.pyc", line 446, in runcommand
File "tortoisehg\hgqt\run.pyc", line 498, in _runcommand
File "tortoisehg\hgqt\run.pyc", line 451, in checkargs
File "tortoisehg\hgqt\run.pyc", line 444, in <lambda>
File "tortoisehg\hgqt\qtapp.pyc", line 527, in __call__
File "tortoisehg\hgqt\qtapp.pyc", line 443, in _fixapplicationfont
File "ctypes\__init__.pyc", line 387, in __getattr__
File "ctypes\__init__.pyc", line 392, in __getitem__
AttributeError: function 'SystemParametersInfoForDpi' not found
```https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5922AttributeError: 'function' object has no attribute 'norepo' 6.4.52023-07-26T19:11:21ZR LAttributeError: 'function' object has no attribute 'norepo' 6.4.5Hi,
I believe I had 4.6.1 installed previously and it was working perfectly.
I recently updated to 6.4.5, and every time I "Detect outgoing changes" the following error message appears.
At first it was complaining about mercurial_keyrin...Hi,
I believe I had 4.6.1 installed previously and it was working perfectly.
I recently updated to 6.4.5, and every time I "Detect outgoing changes" the following error message appears.
At first it was complaining about mercurial_keyring and flow.
It continued to have this error after removing those extensions.
Eventually, I changed my .hgrc to have any empty extensions section.(removing rebase, purge, eol)
However, I see that 'largefiles' + 'strip' are still loaded.
I'm not sure what to do as it does not provide me any options for pushing besides 'push all', which I do not want to do.
% hg log -T {rev}^M -r "452:456 + 461:462 + 465 + 467:468 + 473 + 475:476 + 479 + 481:482 + 485 + 487 + 489:490 + 492:495 + 503 + 574"
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
** Mercurial Distributed SCM (version 6.4.5)
** Extensions loaded: largefiles, strip, tortoisehg.util.hgcommands 6.4.5, tortoisehg.util.hgdispatch 6.4.5, tortoisehg.util.partialcommit 6.4.5, tortoisehg.util.pipeui 6.4.5, tortoisehg.util.win32ill 6.4.5
** unknown exception encountered, please report by visiting
** https://mercurial-scm.org/wiki/BugTracker
** Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)]
** Mercurial Distributed SCM (version 6.4.5)
** Extensions loaded: largefiles, strip, tortoisehg.util.hgcommands 6.4.5, tortoisehg.util.hgdispatch 6.4.5, tortoisehg.util.partialcommit 6.4.5, tortoisehg.util.pipeui 6.4.5, tortoisehg.util.win32ill 6.4.5
Traceback (most recent call last):
File "hg", line 58, in <module>
File "mercurial\dispatch.pyc", line 143, in run
File "mercurial\dispatch.pyc", line 232, in dispatch
File "mercurial\dispatch.pyc", line 276, in _rundispatch
File "mercurial\dispatch.pyc", line 451, in _runcatch
File "mercurial\dispatch.pyc", line 461, in _callcatch
File "mercurial\scmutil.pyc", line 153, in callcatch
File "mercurial\dispatch.pyc", line 441, in _runcatchfunc
File "mercurial\dispatch.pyc", line 1266, in _dispatch
File "mercurial\dispatch.pyc", line 899, in runcommand
File "mercurial\dispatch.pyc", line 1278, in _runcommand
File "mercurial\dispatch.pyc", line 1264, in <lambda>
File "mercurial\util.pyc", line 1881, in check
File "mercurial\commands.pyc", line 6652, in serve
File "mercurial\server.pyc", line 166, in runservice
File "mercurial\commandserver.pyc", line 461, in run
File "mercurial\commandserver.pyc", line 395, in serve
File "mercurial\commandserver.pyc", line 369, in serveone
File "mercurial\commandserver.pyc", line 350, in runcommand
File "mercurial\commandserver.pyc", line 289, in _dispatchcommand
File "mercurial\dispatch.pyc", line 232, in dispatch
File "mercurial\dispatch.pyc", line 276, in _rundispatch
File "mercurial\dispatch.pyc", line 451, in _runcatch
File "mercurial\dispatch.pyc", line 461, in _callcatch
File "mercurial\scmutil.pyc", line 153, in callcatch
File "mercurial\dispatch.pyc", line 441, in _runcatchfunc
File "tortoisehg\util\hgdispatch.pyc", line 27, in _dispatch
File "mercurial\dispatch.pyc", line 1204, in _dispatch
File "mercurial\dispatch.pyc", line 707, in __getattr__
File "mercurial\pycompat.pyc", line 358, in w
AttributeError: 'functools.partial' object has no attribute 'norepo'
cmdserver: process exited unexpectedly with code 255https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5921Rebase window default button2023-07-26T02:14:28ZCarl ReinkeRebase window default buttonIn older versions of TortoiseHg, in the "Rebase" window, the "Rebase" button was the default button (when available) and the "Close" button was the default button after the rebase succeeded. So I could open initiate a rebase, hit Enter,...In older versions of TortoiseHg, in the "Rebase" window, the "Rebase" button was the default button (when available) and the "Close" button was the default button after the rebase succeeded. So I could open initiate a rebase, hit Enter, and it would go, and if there is nothing to resolve, hit Enter again, and it would close the window. At some point, this was changed so that the default button is "Cancel" before the rebase and no default button after.
I'd appreciate it if a no-conflict rebase was just "Enter, Enter" again.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5915error2024-01-28T02:30:41ZZhecheverror```python
** Mercurial version (6.4.5). TortoiseHg version (6.4.5)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1252
** Extensions loaded: strip, tortoisehg.util.configitems
** Python version: 3.9.13 (tags/v3.9.13:6de2ca5, Ma...```python
** Mercurial version (6.4.5). TortoiseHg version (6.4.5)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1252
** Extensions loaded: 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\manifestmodel.pyc", line 439, in fetchMore
File "tortoisehg\hgqt\manifestmodel.pyc", line 498, in _populateNodes
File "tortoisehg\hgqt\manifestmodel.pyc", line 703, in _populaterepo
File "tortoisehg\hgqt\manifestmodel.pyc", line 735, in _populatesubrepos
File "mercurial\util.pyc", line 1760, in __get__
File "mercurial\context.pyc", line 170, in substate
File "mercurial\subrepoutil.pyc", line 78, in state
File "mercurial\context.pyc", line 1576, in __contains__
File "mercurial\dirstate.pyc", line 573, in get_entry
File "mercurial\dirstatemap.pyc", line 113, in get
File "mercurial\util.pyc", line 1760, in __get__
File "mercurial\dirstatemap.pyc", line 307, in _map
File "mercurial\dirstatemap.pyc", line 418, in read
File "mercurial\util.pyc", line 1835, in wrapper
RuntimeError: unknown state: ` ` (0, 0, 0)
```https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5914No direct way to revert multiple revisions2023-07-11T19:02:34ZPhilippe CloutierNo direct way to revert multiple revisionsTortoiseHg allows reverting a changeset by selecting it and using the "Backout..." item of the contextual menu.
When one has several revisions to revert, there is unfortunately no way to revert them all directly. One has to select the l...TortoiseHg allows reverting a changeset by selecting it and using the "Backout..." item of the contextual menu.
When one has several revisions to revert, there is unfortunately no way to revert them all directly. One has to select the last, do "Backout...", then select the pre-last and back that one out too, until the first. Not only does this take more time, but it results in as many new commits as the number of reverted revisions. It would be better if, when multiple commits are selected, the contextual menu still offered "Backout...".
This affects TortoiseHg 6.4.2.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5913Please release an 6.4.x update due to upstream Mercurial bug2023-07-13T18:29:41ZMarc SchlaichPlease release an 6.4.x update due to upstream Mercurial bugThere is a serious issue in Mercurial 6.4.2 (see http://markmail.org/message/ecgbcqjt3pn6dww4 or https://repo.mercurial-scm.org/hg/rev/a445194f0a4d) breaking some repositories.
Could you please release a new version containing that bugfix?There is a serious issue in Mercurial 6.4.2 (see http://markmail.org/message/ecgbcqjt3pn6dww4 or https://repo.mercurial-scm.org/hg/rev/a445194f0a4d) breaking some repositories.
Could you please release a new version containing that bugfix?https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5912Missing api-ms-win-core-path-l1-1-0.dll on Windows 7 with TortoiseHG 6.4.2 x642023-07-28T07:42:33ZMingunMissing api-ms-win-core-path-l1-1-0.dll on Windows 7 with TortoiseHG 6.4.2 x64Latest version of TortoiseHG x64 (6.4.2) do not starting in Windows 7 with error «Missing **api-ms-win-core-path-l1-1-0.dll**».
[Update for Universal C Runtime in Windows](https://support.microsoft.com/en-us/topic/update-for-universal-c...Latest version of TortoiseHG x64 (6.4.2) do not starting in Windows 7 with error «Missing **api-ms-win-core-path-l1-1-0.dll**».
[Update for Universal C Runtime in Windows](https://support.microsoft.com/en-us/topic/update-for-universal-c-runtime-in-windows-c0514201-7fe6-95a3-b0a5-287930f3560c) already installed.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5911Wrong monospace font selected by TortoiseHg2023-07-06T13:13:58ZAugust KarlstromWrong monospace font selected by TortoiseHg**Preconditions**
On a Debian system the Monospace font is associated with the font DejaVu Sans Mono:
```
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
```
This makes GTK applications, like the text editor Pluma, an...**Preconditions**
On a Debian system the Monospace font is associated with the font DejaVu Sans Mono:
```
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
```
This makes GTK applications, like the text editor Pluma, and Qt applications, like the text editor TEA, use the font DejaVu Sans Mono when Monospace is selected.
TortoiseHg version 6.3.1 with Mercurial-6.3.2, Python-3.11.2, PyQt-5.15.9, Qt-5.15.8 is installed.
**What does the user do?**
1. Launches TortoiseHg and opens _File_ -> _Settings_ -> _Fonts_
2. Sets _Diff Font_ to "Monospace, 9pt" and closes the settings window
3. Clicks on a row in the list of commits.
![image](/uploads/58f182cfed2f9aa9b7db8c9cde85a962/image.png)
**What happens?**
The font used for the diff is Courier
![image](/uploads/c27fa1634893ec8da4a2dbd207de7882/image.png)
**What should happen?**
The font used for the diff is DejaVu Sans Monohttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5910blocking RuntimeError2024-01-28T02:30:41Znestoreblocking RuntimeErrorhere is the exception the apperas on every command
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command: --nofork workbench
** CWD: C:\Users\marenco\OneDrive - portsofgenoa.com\Desktop
** Encoding: cp1252
** Ext...here is the exception the apperas on every command
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command: --nofork workbench
** CWD: C:\Users\marenco\OneDrive - portsofgenoa.com\Desktop
** Encoding: cp1252
** Extensions loaded: 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\status.pyc", line 752, in run
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 1902, in _dirstatestatus
File "mercurial\context.pyc", line 1576, in __contains__
File "mercurial\dirstate.pyc", line 573, in get_entry
File "mercurial\dirstatemap.pyc", line 112, in get
File "mercurial\util.pyc", line 1760, in __get__
File "mercurial\dirstatemap.pyc", line 276, in _map
File "mercurial\dirstatemap.pyc", line 374, in read
File "mercurial\util.pyc", line 1835, in wrapper
RuntimeError: unknown state: `` (0, 0, 0)
I try to mahe hg update , hg merge -r ..., hg pull, hg status: on every command the same error
Could someone halp me ?
thankshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5909docdiff broken without user feedback2023-07-05T14:53:03ZRainer Bauerdocdiff broken without user feedbackTortoiseHg 6.4.2
When trying to compare a docx document with the docdiff tool nothing happens.
When I call docdiff directly on the command line, an exception occurs:
```
"C:\Program Files\TortoiseHg\docdiff.exe" "Path to docx file" "Pa...TortoiseHg 6.4.2
When trying to compare a docx document with the docdiff tool nothing happens.
When I call docdiff directly on the command line, an exception occurs:
```
"C:\Program Files\TortoiseHg\docdiff.exe" "Path to docx file" "Path to other docx file"
Traceback (most recent call last):
File "docdiff.py", line 114, in <module>
File "docdiff.py", line 105, in main
File "mercurial\encoding.pyc", line 253, in unifromlocal
File "mercurial\encoding.pyc", line 227, in fromlocal
TypeError: a bytes-like object is required, not 'list'
```
Question: Would it be possible that errors from docdiff are propagated to the UI, so that the user has a feedback that something went wrong?
I tried some older thg versions (that I had lying around locally). Here is the result:
```
5.9.3 OK
6.2.1 Exception
6.4.2 Exception
```
I also tried to change the codepage in the command window to "chcp 1252" before starting docdiff, but the error persisted. I did not change hgencoding!
Would be nice if this regression could be fixed. In the meantime I am restricted to use the 5.9.3 version when I want to compare Office documents.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5908Generated patches lose binary file changes2023-06-27T03:21:49ZPhilippe CloutierGenerated patches lose binary file changesTortoiseHg 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/5907Embedded diffs show "No newline at end of file" in green even without changes...2023-06-19T21:48:12ZPhilippe CloutierEmbedded diffs show "No newline at end of file" in green even without changes to the endWhen 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/5906Console autocomplete of hg* crashes2023-06-27T01:32:37ZPhilippe CloutierConsole autocomplete of hg* crashesCommand autocomplete in the console using the _Tab_ key is mostly broken:
1. Trying to complete "h", "he" or "hel" fails... until help is run. After, completion works.
1. Trying to complete "hg" or hg *" ("hg" followed by a space followe...Command autocomplete in the console using the _Tab_ key is mostly broken:
1. Trying to complete "h", "he" or "hel" fails... until help is run. After, completion works.
1. Trying to complete "hg" or hg *" ("hg" followed by a space followed by any string, for example "hg diff", "hg @" or "hg z") crashes TortoiseHg as soon as Tab is pressed, with the following error:
```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\windows\System32
** Encoding: cp1252
** Extensions loaded: 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\docklog.pyc", line 398, in completeCommandText
File "tortoisehg\hgqt\docklog.pyc", line 344, in _commandComplete
File "tortoisehg\hgqt\docklog.pyc", line 340, in findhgcmd
TypeError: a bytes-like object is required, not 'str'
```
This affects Windows 10 and happens everytime.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5905win32mbcs b'os.path' error in python32023-07-05T15:06:28ZZipherwin32mbcs b'os.path' error in python3I am using Window 10 22H2 x64 version. After upgrade tortoiseHg to "tortoisehg-6.2-x64.msi", each time I close workbench there will be a error message:
![2023-06-05_3108](/uploads/5874130c233a962777c4f1c1829b7231/2023-06-05_3108.png)
I...I am using Window 10 22H2 x64 version. After upgrade tortoiseHg to "tortoisehg-6.2-x64.msi", each time I close workbench there will be a error message:
![2023-06-05_3108](/uploads/5874130c233a962777c4f1c1829b7231/2023-06-05_3108.png)
In thgw.log, it reads:
```
Traceback (most recent call last):
File "mercurial\extensions.pyc", line 270, in _runextsetup
File "hgext\win32mbcs.pyc", line 207, in extsetup
File "hgext\win32mbcs.pyc", line 158, in wrapname
KeyError: b'os.path'
*** failed to set up extension win32mbcs: b'os.path'
```
If I rollback to tortoisehg-6.1.3-x64.msi, there will be no error. And python2 is used in this version.
![2023-06-05_3110](/uploads/abfd9cf27b1aa4cd5fe81f709119507e/2023-06-05_3110.png)
I tried from tortoisehg-6.2-x64.msi to tortoisehg-6.4.2-x64.msi. All of them used python3 and have the same issue.
![2023-06-05_3109](/uploads/a2db8d905fe3818df1a01d7efd48ac7a/2023-06-05_3109.png)
I found an issue in python3 may be relative to this
[issue 13247: under Windows, os.path.abspath returns non-ASCII bytes paths as question marks](https://bugs.python.org/issue13247)
Hope this can help.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5904Update not possible => Path contains invalid component2023-05-24T03:39:42ZMichael HutterUpdate not possible => Path contains invalid componentI 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/5903mercurial.error.ProgrammingError: calling `wrap` after the dirstate was inval...2023-05-23T05:26:24ZWajid Ali Mohammedmercurial.error.ProgrammingError: calling `wrap` after the dirstate was invalidated error with 6.4.2 version.```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\Program Files\TortoiseHg
** Encoding: cp1252
** Extensions loaded: eol, largefiles, mercurial_keyring unknown, strip, tortoisehg.util.configitems...```python
** Mercurial version (6.4.2). TortoiseHg version (6.4.2)
** Command:
** CWD: C:\Program Files\TortoiseHg
** Encoding: cp1252
** Extensions loaded: eol, largefiles, mercurial_keyring unknown, 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\cmdui.pyc", line 649, in runCommand
File "tortoisehg\hgqt\update.pyc", line 398, in runCommand
File "tortoisehg\hgqt\update.pyc", line 342, in isclean
File "mercurial\context.pyc", line 1460, in modified
File "mercurial\util.pyc", line 1760, in __get__
File "mercurial\context.pyc", line 1425, in _status
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
```