Rebase local/remote reversed for tree conflicts
What steps will reproduce the problem?
mkdir main && cd main && git init
touch a.txt && git add a.txt && git commit -m "first"
cd .. && git clone main clone
- Modify clone's a.txt and commit.
- Delete main's a.txt and commit.
- Inside clone, Git Sync -> Fetch & Rebase -> Start Rebase.
- Double-click on the conflicted a.txt to show the tree conflict information.
What is the expected output? What do you see instead?
Expected: Local Modified, Remote Deleted.
Actual: the opposite, which is confusing.
Also: if I abort the popup, and just right-click "Resolve as theirs", and confirm, the file remains shown as conflicted in the list and clicking on Commit results in:
git.exe update-index [...]
error: a.txt: does not exist and --remove not passed
fatal: Unable to process path a.txt
If I press F5 after resolving, the file disappears from the list and then the commit succeeds, deleting the file as expected (ie. mine/theirs is NOT incorrect in the menu, just in the dialog).
If I try to "Resolve as mine", then the file remains in the list as conflicted, but will still commit successfully (as re-adding the file) even without pressing F5.
What version of TortoiseGit and Git are you using? On what operating system?
- TortoiseGit 2.3.4.0 (20161121-ddb9cc6f)
- git version 2.9.3.windows.2
- Windows 8.1 x64
Please provide any additional information below.
Where the conflict is a text modification on both sides rather than a tree conflict, the merge tool is launched with LOCAL being the current branch and REMOTE being the remote branch, as expected (and opposite from what tree conflicts do).