Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • TortoiseGit TortoiseGit
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 382
    • Issues 382
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 16
    • Merge requests 16
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • TortoiseGitTortoiseGit
  • TortoiseGitTortoiseGit
  • Issues
  • #2872
Closed
Open
Issue created Nov 23, 2016 by Gavin Lambert@uecasm

Rebase local/remote reversed for tree conflicts

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).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking