Incomprehensible behavior of 'Resolve'-GUI on certain rebases

[hoeller]

I encountered the following quirk of the Resolve-Merge-Conflict-Screen in Fork 2.17 for macOS:

1. I have a branch introducing a new file (bar.txt) to some directory A.
2. In the meantime, on main other files were moved from this directory A to a directory B.
3. Rebasing the branch onto main now results in a merge conflict.
4. The 'Resolve'-GUI of Fork looks like this: This looks strange at first because it shows a changed file dirB/bar.txt on main even though it did not exist on that branch. The behavior of the GUI is the following:
   • When deselecting the left item and clicking "Choose 'main'" nothing happens and the GUI resets.
   • When clicking "Merge in Fork" the merge window opens briefly and nothing happens.
   • Only choosing the branch on the left (so doing 'git add dirB/bar.txt') resolves the conflict and allows to continue rebase.

I do not understand the internals of git well enough - but I assume the behavior of the rebase itself is the desired one. So is this a problem with the fork GUI in that it currently cannot comprehensibly represent this special case of a merge conflict?

I set up a minimal working example in case someone likes to see this unfold directly: https://github.com/hoeller/mwe-fork-rebases

[DanPristupov]

Thank you for the repo 👍. I will have a look on the weekend.

[DanPristupov]

1. I have a branch introducing a new file (bar.txt) to some directory A.
2. In the meantime, on main other files were moved from this directory A to a directory B.

Git rebase displays the following error:

CONFLICT (file location): dirA/bar.txt added in cc8e091 (Adding another file to the first directory) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dirB/bar.txt.

We cannot merge here. And the first issue in Fork is that the merge buttons must be disabled (we can do that).

How to resolve the conflict though? Logically, there are 2 choices:

• use new folder dirB/bar.txt (main)
• keep using the old folder dirA/bar.txt (one-more-file)

However on the technical side we have a problem because git only reports the old file path and doesn't allow to request it. So, while user can read the conflict description, that info is not stored anywhere in the repository making impossible for Fork to know the other file path.

It looks like right now I don't know how to fix that case.

For the reference, here are the infos returned by git:

$ git status --porcelain
UA dirB/bar.txt

$ git ls-files --unmerged
100644 85b42d76759d51bfc6f54aa70a14f382251f9755 3       dirB/bar.txt

[hoeller]

Thanks a lot for your quick reply. Interesting to see that there are cases that cannot be represented even by such a comprehensive tool because git doesn't provide the data. Anyway, looking forward to some update disabling the sneaky buttons. Keep up the good work, appreciate it!

[DanPristupov]

Let's keep it open, since the problem still exists.