thg issueshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues2024-03-13T04:20:11Zhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5969[Qt6] Right click action on changed file2024-03-13T04:20:11ZAndré Klitzing[Qt6] Right click action on changed fileHi,
I tried Qt6 (with Mercurial-6.6.3, Python-3.11.8, PyQt-6.6.1, Qt-6.6.2) here.
If I have changed files in "Commit view" it was possible to right click that files and select "Revert..." or something like this. But that action don't do...Hi,
I tried Qt6 (with Mercurial-6.6.3, Python-3.11.8, PyQt-6.6.1, Qt-6.6.2) here.
If I have changed files in "Commit view" it was possible to right click that files and select "Revert..." or something like this. But that action don't do anything anymore after the "Discard changes" dialog button.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5968[Qt6] "Commit/Amend" button is not shown correctly2024-03-28T09:04:16ZAndré Klitzing[Qt6] "Commit/Amend" button is not shown correctlyI tried Qt6 (with Mercurial-6.6.3, Python-3.11.8, PyQt-6.6.1, Qt-6.6.2) here. Seems the Commit/Amend button is not shown correctly.
![Screenshot_20240311_155014](/uploads/58022c162833ecb3c26b7ee092c8f667/Screenshot_20240311_155014.png)I tried Qt6 (with Mercurial-6.6.3, Python-3.11.8, PyQt-6.6.1, Qt-6.6.2) here. Seems the Commit/Amend button is not shown correctly.
![Screenshot_20240311_155014](/uploads/58022c162833ecb3c26b7ee092c8f667/Screenshot_20240311_155014.png)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5967Big Git Repo Pull takes a lot of time (more than 48h)2024-02-28T11:17:38ZAndrey HohutkinBig Git Repo Pull takes a lot of time (more than 48h)Windows 10. I want to clone, for example, this repo using hg-git: `git+ssh://git@github.com:strapi/strapi.git`
thg.exe after few minutes gets slow, takes a lot of CPU and doesn't respond. It works but extremely slow.
If I pull the same...Windows 10. I want to clone, for example, this repo using hg-git: `git+ssh://git@github.com:strapi/strapi.git`
thg.exe after few minutes gets slow, takes a lot of CPU and doesn't respond. It works but extremely slow.
If I pull the same repo using command line: `hg pull --verbose` it goes very well without slownesshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5966Crash When Updateing With Git Support Installed2024-02-26T01:40:26ZJohn SchneidermanCrash When Updateing With Git Support InstalledI have the git support enabled, and working on a repository that is a pure Mercurial one. It crashes attempting to look for a git repository. I've attached the generated [bugreport.txt](/uploads/32275e7e7412a0e96cc735bbb29c66eb/bugreport...I have the git support enabled, and working on a repository that is a pure Mercurial one. It crashes attempting to look for a git repository. I've attached the generated [bugreport.txt](/uploads/32275e7e7412a0e96cc735bbb29c66eb/bugreport.txt) file.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5961Subtle dual use of Ctrl+Shift+E is confusing2024-01-12T00:43:41ZDavid HollmanSubtle dual use of Ctrl+Shift+E is confusingIf the `☆ Working Directory ☆` line is highlighted:
- <kbd>Ctrl+Shift+E</kbd> performs "Edit Local" on a selected file
But if a past commit is highlighted:
- <kbd>Ctrl+Shift+E</kbd> performs "View at Revision" on a selected file
I alwa...If the `☆ Working Directory ☆` line is highlighted:
- <kbd>Ctrl+Shift+E</kbd> performs "Edit Local" on a selected file
But if a past commit is highlighted:
- <kbd>Ctrl+Shift+E</kbd> performs "View at Revision" on a selected file
I always found this dual use confusing and hard to remember what it would do. I think this is reinforced because whether you open the local copy of a file or a prior revision, the editor that comes up looks almost exactly the same.
Personally I think it would be preferable if the hotkey always retained the same exact meaning. Since "Edit Local" exists in both contexts, probably it should have the same hotkey all the time.
Thankshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5956Amend may fail with "Nothing changed" when trying to cancel change2023-11-21T14:13:52ZPhilippe CloutierAmend may fail with "Nothing changed" when trying to cancel changeUsing TortoiseHg 6.5.1, if one accidentally includes changes to file _x_ in a commit and tries using _Amend_ to cancel changes to _x_, the commit can keep the unwanted changes. If the amendment only consists of such cancellations, the am...Using TortoiseHg 6.5.1, if one accidentally includes changes to file _x_ in a commit and tries using _Amend_ to cancel changes to _x_, the commit can keep the unwanted changes. If the amendment only consists of such cancellations, the amendment attempt can fail with a dialog titled "Nothing Committed" which contains:
> Nothing changed.
This is because the way to cancel a change is unintuitive/inefficient/confusing. The user will most likely try something like the following:
0. Create a commit with (for example) modifications to 2 files
1. Select the _* Working Directory *_ line (top)
1. Click on the arrow to the right of _Commit_
1. Select _Amend current revision_
1. Uncheck a file (left)
1. Activate the _Amend_ button (right)
To properly cancel a change to a file, one can either:
* Instead of step #4, modify the mistakenly changed file to bring its contents back to its earlier state. This could for example be done with a text editor.
* or strip the incorrect commit using Strip's `--keep` option and perform a new commit to replace it.
This is related to ticket #3251 .https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5952Network drive letters are converted to UNC paths2023-11-28T19:01:10ZMichael StammbergerNetwork drive letters are converted to UNC pathsI have a lot of repositories located on a network drive (Windows Server, mapped by "net use ...").
After updating from TortoiseHg 6.0.0 to 6.5.1. the Workbench handle these repositories in a strange way:
- The repositories are listed in...I have a lot of repositories located on a network drive (Windows Server, mapped by "net use ...").
After updating from TortoiseHg 6.0.0 to 6.5.1. the Workbench handle these repositories in a strange way:
- The repositories are listed in the Repository registry (TreeView) as before.
- On opening one of these repositories by double click the Workbench freezes for some time before opening it.
- Then the repository **is added a second time** to the Repository registry, but with a different icon (planet earth probably representing a network connection).
- The path to the new added repository has changed from the network drive letter to its UNC path (and this new added repository is actually opened).
The problem with the UNC path is that the Windows command line can't work with them correctly. Some hooks are not processed as expected, e.g. changegroup:
> % hg push "N:\Projects\MyProject"\
> pushing to N:\Projects\MyProject\
> searching for changes\
> adding changesets\
> adding manifests\
> adding file changes\
> added 79 changesets with 308 changes to 53 files (+1 heads)\
> "\\\\SRV6\Entwicklung\Projects\MyProject"\
> **CMD.EXE wurde mit dem oben angegebenen Pfad als aktuellem Verzeichnis gestartet.**\
> **UNC-Pfade werden nicht unterstützt.**\
> **Stattdessen wird das Windows-Verzeichnis als aktuelles Verzeichnis gesetzt.**\
> abort: no repository found in 'C:\Windows' (.hg not found)\
> warning: changegroup hook exited with status 255\
> [command completed successfully Fri Sep 29 12:11:56 2023]
Why is the network drive letter path replaced by UNC path?
TortoiseHg version 6.5.1 with Mercurial-6.5.1, Python-3.9.13, PyQt-5.15.7, Qt-5.15.2, Windows 10 Pro 22H2.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5949UI becomes unresponsive when creating a new branch2023-08-30T01:56:27ZPierre-Étienne MessierUI becomes unresponsive when creating a new branchWe use THG 5.9.1 on Windows 10 on a very large repo. On a daily basis on the default branch, the UI of THG is responsive.
When we create a new branch and this branch is selected in the branch filter on the upper right, every commit/pull...We use THG 5.9.1 on Windows 10 on a very large repo. On a daily basis on the default branch, the UI of THG is responsive.
When we create a new branch and this branch is selected in the branch filter on the upper right, every commit/pull/rebase makes the UI unresponsive for several seconds.
This do NOT happen:
- If "★ Show all ★" is selected
- When there is enough commits in the branch, the problem is not happening anymore.
- When the repo is small
I tried THG 6.5.1 and the problem is still there.
Is there some logs I could provide to help investigating this issue?https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5948Cannot commit to new repository2023-08-23T18:59:30ZJohn LaughlinCannot commit to new repositoryCreated a new repository and cannot do an initial commit. Every time I commit it yields the message:
cmdserver: process exited unexpectedly with code -1073741819
I've tried running a traceback or debug but it always yields...Created a new repository and cannot do an initial commit. Every time I commit it yields the message:
cmdserver: process exited unexpectedly with code -1073741819
I've tried running a traceback or debug but it always yields the same output.
hg commit -y --debug --traceback --logfile 'logfile'
cmdserver: Process crashed
cmdserver: process exited unexpectedly...
Note TortoiseHg is a fresh install and I've only configured the username in global settings.
Using TortoiseHg ver 4.0.2
Mercurial-4.0.2, Python-2.7.10, PyQt-4.11.4, Qt-4.8.7https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5941FILING REPORTS (CREATING TICKETS ON THIS ITS) IS BROKEN2023-11-28T19:01:10ZPhilippe CloutierFILING REPORTS (CREATING TICKETS ON THIS ITS) IS BROKENTortoiseHg Shelve allows to apply patches or parts of patches, but this can fail. When some patch chunks are rejected, a _Manually resolved rejected chunks?_ dialog shows offering the user to open a resolution tool, whose operation is un...TortoiseHg Shelve allows to apply patches or parts of patches, but this can fail. When some patch chunks are rejected, a _Manually resolved rejected chunks?_ dialog shows offering the user to open a resolution tool, whose operation is unfortunately far from clear (and fairly broken).
While that operation *is* documented, finding that documentation is unfortunately hard, for a couple reasons:
1. There is no in-place documentation, and [the section documenting shelving (5.8. Shelve)](https://tortoisehg.readthedocs.io/en/latest/shelve.html) says no word about that window.
2. The documentation, which can be found in [section 7.6. Patch Rejects](https://tortoisehg.readthedocs.io/en/latest/patches.html#patch-rejects), does not contain the window title's text ("**Merge** rejected patch chunks") except in a screenshot. Instead, it uses the (possibly outdated) label "**Resolve** rejected patch chunks". It also doesn't contain the "Manually resolved rejected chunks?" prompt's content.
While the ideal solution would be to fix the window and make it convenient, it would already help to move the contents of 7.6 to its own section and have sections 7. and 5.8. refer to it.https://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/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/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/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.