Visual conflict resolution interface
Version
0.12.19
Operating System
Mac OS X
Distribution Method
dmg (Apple Silicon)
Describe the issue
Are there any plans to update a visual conflict resolution interface? Ideally, I’m looking for a conflict resolution tool integrated into the IDE, similar to JetBrains, or a UI tool like Fork or GitKraken.
How to reproduce
No response
Expected behavior
No response
Relevant log output
No response
Thanks a lot for asking! Maybe @krlvi knows the answer.
Meanwhile, I'd like to mention #3048 as one way of dealing with this would be to make the conflicts available in Git so existing tools can be used to resolve them.
If the target branch(master) conflicts with the virtual branch(workspace), does that mean we can't resolve it using other tools?
Actually, that's exactly how it works today - one sees conflicts markers in the worktree files and can resolve them there.
Does this mean I can merge the integration branch with the master and resolve conflicts (using other tool)?
Yes, that is the intended workflow.
Is the “GitButler Integration Commit“ in the integration branch something we don't need to pay attention to? I'm concerned that merging might affect it.
It's an artificial and 'managed' commit which is used to show which virtual branches are currently visible, but it won't itself be subject to traditional merges (as long as the user doesn't run git merge manually, that is).
Since gitbutler's branches seem to be named randomly, using other tools for conflict resolution and then cutting back to gitbutler doesn't work
I don't think that using Git manually on any of these branches is the intended workflow. From what I can tell, if a conflict is detected, one can enter 'edit mode' to and resolve the conflict. Tools are guided by an index which indicates the conflicts. When resolved, in GitButler one can exit edit mode and pick up the latest version of the worktree and mark the conflict as resolved.
Probably I am missing something though, and would need details on the workflow you are employing.
This actually brings me to the multiple working branches I mentioned earlier, where I'm rebasing one working branch against another, which gitbutler doesn't have the ability to do at the moment