GitLab

What steps will reproduce the problem?

1. mkdir main && cd main && git init
2. touch a.txt && git add a.txt && git commit -m "first"
3. cd .. && git clone main clone
4. Modify clone's a.txt and commit.
5. Delete main's a.txt and commit.
6. Inside clone, Git Sync -> Fetch & Rebase -> Start Rebase.
7. 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).