thg issueshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues2023-05-04T16:41:15Zhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5863Immediately upon upgrading to THg 6.3.2 (Windows, x64) I get a permission den...2023-05-04T16:41:15ZassarbadImmediately upon upgrading to THg 6.3.2 (Windows, x64) I get a permission denied error regarding the TortoiseHgOverlayServerThe 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/5368Implement default keyboard shortcuts for switching repository Tabs (esp. Ctrl...2020-06-21T11:18:39ZBitbucket ImporterImplement default keyboard shortcuts for switching repository Tabs (esp. Ctrl+(Shift)+Tab)*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
In the entire tabbed IT universe, Ctrl+Tab / Ctrl+Shift+Tab can be used to switch between the last activated ...*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
In the entire tabbed IT universe, Ctrl+Tab / Ctrl+Shift+Tab can be used to switch between the last activated tabs. Browers like Firefox, MDI-Editors like Notepad++, Windows itself with Alt+Tab / Alt+Shift+Tab, you name it: It just works EVERYWHERE. But sadly, NOT in THG...
I have never discovered Ctrl+1, Ctrl+2 etc. for Tab switching in THG until I found #3543 today. Unfortunately, having those keyboard shortcuts on file menu does not make them discoverable enough. Worse, they are not very practical. Anyone having more than 9 repositories can't use them to switch between any tabs beyond tab 9. And depending on workflows, arrangement of tabs may change in between, which spoils the muscle memory. Before I figure out if that tab is tab 7 or tab 8 so that I can press Ctrl+7 or 8 respectively, it's faster to just click on it anyway. But for just switching between 7 and 8 which I happen to use today, and 9 and 10 tomorrow, just using Ctrl+Tab is perfectly memorable as a no-brainer, every time.
In #3543, @yuja objected:
> But "ordered by last activation" will increase the complexity of the big Workbench class.
> It'll be necessary to factor out tab-related functions first.
I think that's not true. "Ordered by last activation" is quite simple, just keep a single array with tab indices, ordered by tab activation, last activated first. Here's a rough sketch how (pseudo code leaning on javascript syntax; I don't know Python):
````
let globalTabSwitchSeqArray = [];
function onTabFocusEventHandler() {
let currentTabIndex = tabsObject.getCurrentTabIndex(); // Index: 1st tab = 0 etc.
if (!globalTabSwitchSeqArray[currentTabIndex]) {
// add new tab id to start of tab switch array
globalTabSwitchSeqArray.unshift(currentTabIndex); // when opening e.g. 3rd tab: [2, 1, 0]
} else {
// existing tab focused, e.g. Tab 2, move it to begin of tab-switch-array
array_move(globalTabSwitchSeqArray, globalTabSwitchSeqArray.indexOf(currentTabIndex), 0);
// new tab switch order: [1,2,0]
}
}
function workbenchOnKeyPress (event) {
if (event.key == "Tab" && event.CtrlKey) {
if (event.ShiftKey) {
// backwards in activation sequence: activate last tab in the sequence
targetIndex = globalTabSwitchSeqArray.length-1;
switchToTab(globalTabSwitchSeqArray[targetIndex]);
} else {
// forward in activation sequence: activate 2nd tab in the sequence
switchToTab(globalTabSwitchSeqArray[1]);
}
}
}
function array_move(arr, old_index, new_index) {
if (new_index >= arr.length) {
var k = new_index - arr.length + 1;
while (k--) {
arr.push(undefined);
}
}
arr.splice(new_index, 0, arr.splice(old_index, 1)[0]);
return arr; // for testing
};
````
I haven't tested this in any way, but hopefully it's enough to get the idea.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4588importing mimetypes raises TypeError (Windows)2020-06-21T11:02:20ZBitbucket Importerimporting mimetypes raises TypeError (Windows)*Created originally on Bitbucket by [radzioreku (Radosław Urbanik)](https://bitbucket.org/%7B06016386-f4f5-4449-b79d-cfadfcf3ef28%7D/)*
Errors occured
The logfile 'C:\Program Files\TortoiseHg\thgw.exe.log' could not be opened: [Errno...*Created originally on Bitbucket by [radzioreku (Radosław Urbanik)](https://bitbucket.org/%7B06016386-f4f5-4449-b79d-cfadfcf3ef28%7D/)*
Errors occured
The logfile 'C:\Program Files\TortoiseHg\thgw.exe.log' could not be opened: [Errno 13] Permission denied: 'C:\\Program Files\\TortoiseHg\\thgw.exe.log'
This shows everytime. Can not use thg.
configuration: Windows 10, thg 3.9.0, after upgrade from thg 3.7.1.
*Attachments:* [thg-output.txt](/uploads/c9988319ee31fc28340fdb84826cc53a/thg-output.txt)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4395Import patch default target2020-06-21T10:58:15ZBitbucket ImporterImport patch default target*Created originally on Bitbucket by [psuter (Peter Suter)](https://bitbucket.org/%7B48b289e8-68dd-4aa4-8d3a-6458c5363d69%7D/)*
The import patch dialog has a *target* combobox were *Repository*, *Shelf*, *Working Directory* or the name o...*Created originally on Bitbucket by [psuter (Peter Suter)](https://bitbucket.org/%7B48b289e8-68dd-4aa4-8d3a-6458c5363d69%7D/)*
The import patch dialog has a *target* combobox were *Repository*, *Shelf*, *Working Directory* or the name of the active MQ patch queue can be selected. Currently by default always *Repository* is selected.
Would it be possible to configure the default or remember the previous selection of that combobox? (E.g. so by default always the active MQ patch queue is selected.)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/3684Import patch into patch queue fails with # in filename2020-06-21T10:43:00ZBitbucket ImporterImport patch into patch queue fails with # in filename*Created originally on Bitbucket by [fknol (Frank Knol)](https://bitbucket.org/%7Ba83dfdbc-eea0-4665-aea4-90f46755b73e%7D/)*
Seen in TortoiseHg version 2.9
Patches can be created with a # in the filename, but when trying to import th...*Created originally on Bitbucket by [fknol (Frank Knol)](https://bitbucket.org/%7Ba83dfdbc-eea0-4665-aea4-90f46755b73e%7D/)*
Seen in TortoiseHg version 2.9
Patches can be created with a # in the filename, but when trying to import the same patch file to the patches, the command fails with the following error:
abort: "#" cannot be used in the name of a patch
Renaming the file does the trick
https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4750Improve branch color hashing2020-06-21T11:05:54ZBitbucket ImporterImprove branch color hashing*Created originally on Bitbucket by [schlamar (Marc Schlaich)](https://bitbucket.org/%7B0ed8ebc9-2100-466d-9d4d-dbd5d2caed79%7D/)*
The current branch coloring strategy is pretty bad for versioned branch names as it collides very often.
...*Created originally on Bitbucket by [schlamar (Marc Schlaich)](https://bitbucket.org/%7B0ed8ebc9-2100-466d-9d4d-dbd5d2caed79%7D/)*
The current branch coloring strategy is pretty bad for versioned branch names as it collides very often.
E.g. `_hashcolor('V1_2') == _hashcolor('V2_1') == _hashcolor('V3_0')`.
Additionally, the color for these branch names is the default blue color. So everything is blue if you have these active 4 branches. This is really ugly!
My proposals:
* Do not reuse the "default" color. It's very likely that the default branch is always active and near top, so another branch shouldn't get this color.
* Use a proper hash function instead of `sum(ord(...` to prevent collisions in versioned branches
Keywords: colour, colouringhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4957Improve rebase dialog: Use phase to swap source / destination etc.2020-06-21T11:09:59ZBitbucket ImporterImprove rebase dialog: Use phase to swap source / destination etc.*Created originally on Bitbucket by Anonymous*
In `RepoWidget` `rebaseDlg` two selected revisions are used as source and destination of the rebase operation: `{'source': self.menuselection[0], 'dest': self.menuselection[1]}`.
For som...*Created originally on Bitbucket by Anonymous*
In `RepoWidget` `rebaseDlg` two selected revisions are used as source and destination of the rebase operation: `{'source': self.menuselection[0], 'dest': self.menuselection[1]}`.
For some reason this order is always counter-intuitive to me. To me it seems more natural to click the destination first and then right-click the source to open the context menu and execute the rebase command on the source revision.
But I guess just swapping them would confuse users that are now used to this behavior.
I'm very thankful that there is a "Swap source and destination" link/button that can easily fix the problem, if it is noticed. Unfortunately the UI makes it more difficult than necessary to notice the problem: There is a lot of information, but not necessarily all of it is useful and not all useful information is shown.
The phase (secret / draft / public) of the two changesets is missing. When source is public and destination is draft, I probably mixed them up and want to swap them. This could IMO even be done automatically as a heuristic.
To me branch and tag and date are just distracting.
The bold labels are also quite distracting.
More helpful would be "author coloring", but that is missing.
(The source changeset title is missing the word "source".)
The source and destination groupboxes are stacked vertically. It would be much more helpful to stack them horizontally, so the respective fields are next to each other.
Bonus: Show some hints (i.e. colored "source" and "destination" annotations, or an maybe even an arrow from source to destination?) in the workbench graph on the selected changesets themselves.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5366In attempt when creating bisection.2020-06-21T11:18:37ZBitbucket ImporterIn attempt when creating bisection.*Created originally on Bitbucket by Anonymous*
#!python
** Mercurial version (4.7.1). TortoiseHg version (4.7.1)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1251
** Extensions loaded: strip, mq, reb...*Created originally on Bitbucket by Anonymous*
#!python
** Mercurial version (4.7.1). TortoiseHg version (4.7.1)
** Command:
** CWD: C:\Windows\system32
** Encoding: cp1251
** Extensions loaded: strip, mq, rebase, transplant, commitextras, journal, tortoisehg.util.configitems
** Python version: 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 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.9.2 PyQt-5.9.1 QScintilla-2.10.2.dev1711012104
Traceback (most recent call last):
File "tortoisehg\hgqt\bisect.pyo", line 174, in _verifyGood
File "tortoisehg\hgqt\bisect.pyo", line 160, in _lookupRevision
File "tortoisehg\hgqt\thgrepo.pyo", line 772, in __getitem__
File "mercurial\localrepo.pyo", line 856, in __getitem__
File "mercurial\context.pyo", line 439, in __init__
ProgrammingError: unsupported changeid '7' of type <type 'str'>https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5459Include Branch name in default Keyword search2020-06-21T11:20:22ZBitbucket ImporterInclude Branch name in default Keyword search*Created originally on Bitbucket by [James Anderson](https://bitbucket.org/%7Bd3850099-f35c-48ca-a821-ae61817d3ab2%7D/)*
I often want to search for a named branch in the repo, but by default the revision set query \(`Ctrl+S`\) searches ...*Created originally on Bitbucket by [James Anderson](https://bitbucket.org/%7Bd3850099-f35c-48ca-a821-ae61817d3ab2%7D/)*
I often want to search for a named branch in the repo, but by default the revision set query \(`Ctrl+S`\) searches my text using `keyword()` which does not look at the the branch names.
I know that I can type in '`branch(abc)`' or use the separate Search window, or even write the branch name in the commit message \(I do that but not everyone else here does\), however it would be very convenient if `keyword()` also included the branch field, or alternatively if the revision set query could look at both `keyword()` and `branch()` together.
Is this something that could be implemented, or is this just wishful thinking?
If there was a way to override the search behaviour without rebuilding the thg source code I would be happy with that.
Thanks in advance.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4918Incoming deselects target leading to unrestricted pull2020-06-21T11:09:08ZBitbucket ImporterIncoming deselects target leading to unrestricted pull*Created originally on Bitbucket by [psuter (Peter Suter)](https://bitbucket.org/%7B48b289e8-68dd-4aa4-8d3a-6458c5363d69%7D/)*
If I want to pull a bookmark:
1) I create that bookmark.
2) Then I can select that bookmark in "Synchro...*Created originally on Bitbucket by [psuter (Peter Suter)](https://bitbucket.org/%7B48b289e8-68dd-4aa4-8d3a-6458c5363d69%7D/)*
If I want to pull a bookmark:
1) I create that bookmark.
2) Then I can select that bookmark in "Synchronize"->"[x] Target: mybookmark".
3) Then I click "Incoming" to check what will be pulled.
4) Then I click "Pull".
But sometimes step 3) removes the bookmark from "[x] Target: mybookmark", so step 4) pulls everything instead of just the bookmark! This seems quite misleading / inconvenient / error prone.
(Maybe this happens only when the local bookmark is created on a changeset that is not an ancestor of the remote bookmark?)
Thankshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/3861Incoming doesn't allow to view all branches when filter branch is specified2020-06-21T10:46:51ZBitbucket ImporterIncoming doesn't allow to view all branches when filter branch is specified*Created originally on Bitbucket by [NN](https://bitbucket.org/%7Bf66e4503-cb56-489c-b87b-d9fb5db1dd37%7D/)*
When I select a branch in Workbench and then press 'Incoming' I see only my branch.
In case my branch doesn't have any changes...*Created originally on Bitbucket by [NN](https://bitbucket.org/%7Bf66e4503-cb56-489c-b87b-d9fb5db1dd37%7D/)*
When I select a branch in Workbench and then press 'Incoming' I see only my branch.
In case my branch doesn't have any changes I see nothing.
It is 'Found 11 incoming changes' <Accept> <Reject>
There is no option to show the changes from other branches in the incoming.
So I must press 'Reject', switch to all branches, press 'Incoming' again and switch to my branch back.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4636Inconsistent terminology - "revert" vs. "discard"2020-06-21T11:03:27ZBitbucket ImporterInconsistent terminology - "revert" vs. "discard"*Created originally on Bitbucket by [DaveInCaz (David Hollman)](https://bitbucket.org/%7B2dd8bec0-e2b4-43d0-b274-6ee79db66b75%7D/)*
In some places in THG Workbench the "revert" function is called "revert" and in other places "discard". ...*Created originally on Bitbucket by [DaveInCaz (David Hollman)](https://bitbucket.org/%7B2dd8bec0-e2b4-43d0-b274-6ee79db66b75%7D/)*
In some places in THG Workbench the "revert" function is called "revert" and in other places "discard". I think it would be less confusing if a single term were used as a standard.
I suggest "revert" is the better term since that is also the name of the hg command.
Specific places where I have noticed this:
[1] In Commit view, right click on a modified file. Shows "Revert" option. When you select that option, the dialog mixes both terms.
![Capture.PNG](https://bitbucket.org/repo/48R4X/images/1950622182-Capture.PNG)
Suggest changing "Discard changes" to "Revert without Backup"
[2] Rebase window - says "... you must commit, shelve to patch, or discard..."
[3] Merge window - much the same as rebase
[4] Update window - checkbox "Discard local changes..."
[5] Context menu for a revision - "Revert All File..." option. The dialog then states "Reverting all files will discard changes...". Though this is OK since that is just providing a definition of 'revert', the Hg help for revert defines it as "restore files to their checkout state". Maybe using that definition would be more consistent.
There could be other cases, these are all I can think of right now.
Note - I've been introducing THG to several new users recently and these kinds of issues can be real points of confusion for them (when there is so much else to learn about THG / Hg, etc.)
Thankshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4946In context menu of patches in repository list, improve wording of "Apply patc...2020-06-21T11:09:44ZBitbucket ImporterIn context menu of patches in repository list, improve wording of "Apply patch" command*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
The current wording of patch commands in the context menu of patches in repository list is not very clear. "A...*Created originally on Bitbucket by [thomasdd (Thomas D.)](https://bitbucket.org/%7B8da0c5d2-9d85-454e-8331-a0535f3a8cc6%7D/)*
The current wording of patch commands in the context menu of patches in repository list is not very clear. "Apply patch" can easily be misunderstood as "Apply only this patch" but it really means "Apply (all patches) up to this patch".
STR
1. right-click on patch in repository list
2. try to figure out the exact meaning of "Apply patch"
Actual Result:
1. "Apply patch" might be misunderstood as "Apply *only this patch*"
Expected result:
1. "Apply patches up to this patch" (or maybe "Apply all up to this patch" or even just "Apply up to this patch")
[Edited: Sorry, there were some misunderstandings on my side in the first version of this issue]https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/634Incorrect kdiff3 arguments during merge with no base2020-06-21T09:52:09ZBitbucket ImporterIncorrect kdiff3 arguments during merge with no base*Created originally on Bitbucket by Anonymous*
TO REPRODUCE:
Create 2 disjoint repos and attempt to merge them with the "force" option. When resolving conflicts, kdiff3 will be launched with the following settings:
* A =
* B = parent...*Created originally on Bitbucket by Anonymous*
TO REPRODUCE:
Create 2 disjoint repos and attempt to merge them with the "force" option. When resolving conflicts, kdiff3 will be launched with the following settings:
* A =
* B = parent1
* C = parent2
Notice that there is no (A = base). This causes merge problems. A is blank, but its EOL encoding is set Unix, while B and C are set to DOS. Try merging the following files set as B and C in kdiff3 but leave A blank:
* File B:
# Line1 Line1
# Line2 Line2
# Line3 Line3
# Line4 Line4
# Line5 Line5
* File C:
# Line1 Line1
# Line2 Line2
#
# Line3 Line3
# Line4 Line4
# Line5 Line5
Files B and C differ only by a blank new line. Kdiff3 will create huge conflicts, where in fact it should create none. You might say, that this is a kdiff3 bug and not tortoisehg. However I am posting it as a bug here, because tortoisehg can fix it. When there is no base, kdiff3 should be executed in the following way:
* A = parent1
* B = parent2
* C =
*Attachments:* [SampleRepo.zip](/uploads/3c083679bcfa74511b60e39a38fa7fb1/SampleRepo.zip)https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/1502Incorrect line endings inserted in merge rejected patch view2020-06-21T10:09:46ZBitbucket ImporterIncorrect line endings inserted in merge rejected patch view*Created originally on Bitbucket by [grauw (Laurens Holst)](https://bitbucket.org/%7B9d645af2-774b-4220-b9aa-4db38b7835fd%7D/)*
When I am in the merge rejected patch view, if I copy/paste from the diff area into the file editor, it adds...*Created originally on Bitbucket by [grauw (Laurens Holst)](https://bitbucket.org/%7B9d645af2-774b-4220-b9aa-4db38b7835fd%7D/)*
When I am in the merge rejected patch view, if I copy/paste from the diff area into the file editor, it adds the lines with CRLF line endings. I am running on Windows.
Steps for reproduction:
# Import two changesets into MQ that use LF line endings in their files
# Unapply the second patch
# Alter something in the first patch that conflicts with the second
# Re-apply the second patch
# Answer yes to the dialog that asks if you want to merge the rejected hunk
# Copy/paste a couple of lines from the rejected hunk into the file editor
# Mark the hunk as resolved and save
# Note that the file now has mixed line endingshttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/1672incorrectly marked as subrepo in reporegistry ?2020-06-21T10:13:08ZBitbucket Importerincorrectly marked as subrepo in reporegistry ?*Created originally on Bitbucket by [johansamyn (Johan Samyn)](https://bitbucket.org/%7B9c10eb3e-883d-43e9-988f-cdc051634361%7D/)*
Hi,
I made some test repo's, a master, and 2 clones, and for some reason the clones are marked as subr...*Created originally on Bitbucket by [johansamyn (Johan Samyn)](https://bitbucket.org/%7B9c10eb3e-883d-43e9-988f-cdc051634361%7D/)*
Hi,
I made some test repo's, a master, and 2 clones, and for some reason the clones are marked as subrepo's in the reporegistry.
The structure is as follows:
{{{
.../path/to/repos1/master
.../path/to/repos2/clone1
.../path/to/repos2/clone2
}}}
As you can see from the structure the 2 clones are not even really stored in a level directly under the master repo. So I suspect an imperfection in the way the reporegistry detects subrepos.
-- Johanhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4971Incorrect 'Outgoing' lists if log command is aliased2020-06-21T11:10:17ZBitbucket ImporterIncorrect 'Outgoing' lists if log command is aliased*Created originally on Bitbucket by [DaveInCaz (David Hollman)](https://bitbucket.org/%7B2dd8bec0-e2b4-43d0-b274-6ee79db66b75%7D/)*
When I click the outgoing button on the main toolbar THG shows me a list of any draft changesets which D...*Created originally on Bitbucket by [DaveInCaz (David Hollman)](https://bitbucket.org/%7B2dd8bec0-e2b4-43d0-b274-6ee79db66b75%7D/)*
When I click the outgoing button on the main toolbar THG shows me a list of any draft changesets which DO need to be pushed, but then it follows that with apparently all the public changesets which are already synchronized. Confusing.
The second set should not be shown.
Note - I believe this is the same whether I use the main toolbar or the smaller toolbar in sync view.https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5796iniparse optional in tortoisehg deb for Ubuntu 22.042022-05-18T15:15:26Zlong76iniparse optional in tortoisehg deb for Ubuntu 22.04i use command
`sudo apt install tortoisehg`
`python-iniparse` only in recommends package like `python-pygments`
`python-iniparse` must be required and called `python3-iniparse`i use command
`sudo apt install tortoisehg`
`python-iniparse` only in recommends package like `python-pygments`
`python-iniparse` must be required and called `python3-iniparse`https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/4835inotify_add_watch failed2020-06-21T11:07:25ZBitbucket Importerinotify_add_watch failed*Created originally on Bitbucket by [Jgariano (John Gariano)](https://bitbucket.org/%7B26395f32-1347-401b-8f9b-e9cde9f84a90%7D/)*
I am running Ubuntu 16.04 and after installing the most recent version of tortoisehg from the ppa ( versio...*Created originally on Bitbucket by [Jgariano (John Gariano)](https://bitbucket.org/%7B26395f32-1347-401b-8f9b-e9cde9f84a90%7D/)*
I am running Ubuntu 16.04 and after installing the most recent version of tortoisehg from the ppa ( version 3.7.3 with Mercurial-3.7.3, Python-2.7.12, PyQt-4.11.4, Qt-4.8.7). Upon calling thg from the command line I get the following error
QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/muri-john/.config/TortoiseHg/thg-reporegistry.xmlhttps://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5632Installation is a pain, instructions are not complete2020-10-17T17:13:16Zteo1978Installation is a pain, instructions are not completeYou have to understand that, from a user's perspective, installation of thg (and of any other software for that matter) should be as easy as either of these:
- download a file and execute it, or
- copy and paste no more than two or three...You have to understand that, from a user's perspective, installation of thg (and of any other software for that matter) should be as easy as either of these:
- download a file and execute it, or
- copy and paste no more than two or three commands into a terminal.
If it has to be any more complicated than that, then give a reliable and easy to follow set of instructions that one can follow without having to become an expert in Python, its modules and package frameworks, and whatnot.
I don't give a damn about python, I don't want to install python 2 if I'm using python 3 or viceversa, I don't want to have to figure out how to use pip, I shouldn't even have to know that thg is made in python, that's your business, not mine.
So, now I am on a brand new laptop where I **freshly installed OpenSUSE** Tumbleweed. There I installed mercurial with zypper.
Then I googled "TortoiseHG" and clicked on the first result which led me here: https://tortoisehg.bitbucket.io/
Next I click on the big "Download" button which leads me here:
https://tortoisehg.bitbucket.io/download/linux.html
My distro (OpenSUSE) is not listed, so I read the **"From Source"** which says:
> If no package yet exists for your platform, then use the source installing method described on the [thg](https://foss.heptapod.net/mercurial/tortoisehg/thg/-/wikis/thg) page
where "the thg page" links here: https://foss.heptapod.net/mercurial/tortoisehg/thg/-/wikis/thg
It says:
> 1. Install Mercurial (consult the chart at [ReleaseNotes](/mercurial/tortoisehg/thg/-/wikis/ReleaseNotes) for version info)
> 2. Clone the TortoiseHg repository:
> 3. Symlink the thg script into your path:
Note that all the commands to copy and paste are missing, BTW.
> That is usually all you have to do
Yeah, right.
The first thing I got when trying to run the `thg` executable was an error telling me that the command `python` was not found.
I was going to install python but then realized I already have python 3.8 installed on my system, so I symlinked `/usr/bin/python3` to `/usr/bin/python`, so now the `python` command executes python 3.
At https://foss.heptapod.net/mercurial/tortoisehg/thg/-/wikis/thg it doesn't say that you should use python 2 rather than 3, it just says:
> TortoiseHg should work on Python 2.4** or later**
so python 3.8 should be fine. Also, on my older laptop I've been running thg on python 3 for months now without any issue (after a nightmare process that took me several days to get it to work after the upgrade to Ubuntu 20.04 wiped out my preexisting perfectly working older install of thg, just during the period when thg's obsolete official site had been taken down and before it was redirected to the new one - so it took me a few days to discover that thg wasn't just completely abandoned)
So again, python3 should be fine.
So now, with `python` symninked to the `python3` binary, I tried running thg again, and of course I get:
```
ModuleNotFoundError: No module named 'PyQT5'
```
I look back at https://foss.heptapod.net/mercurial/tortoisehg/thg/-/wikis/thg and it does say, at the very bottom of the page:
> We require a minimum PyQt version of 4.6
Ok, well, then first, why did you say:
> 1. Install Mercurial (consult the chart at [ReleaseNotes](/mercurial/tortoisehg/thg/-/wikis/ReleaseNotes) for version info)
> 2. Clone the TortoiseHg repository:
> 3. Symlink the thg script into your path:
>
> That is usually all you have to do
No, presumably you will usually also have to install PyQt, so that should be added to the list.
And secondly, at least give me a link or some hint about how to proceed with that.
I have no idea what PyQt is, and while I love to learn new things, I'll educate myself on the topic at another time; now I was installing TortoiseHG and I expected to be able to do so in a few minutes by just executing a handful of commands, without having to google a bunch of other things.