The only people who disagree are people who don't have regular experience from both sides.
Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui.
I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge.
If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.
I find ediff from Emacs to be superior to the JetBrains conflict resolution view. And I've had to deal with some gnarly (and large) merges at $JOB.
I dunno, something about its keyboard-driven design (and in general being Emacs-based) makes it clearer in usage than the JetBrains offering. Although this is probably what one is used to.
Of course, the really important thing is that people set merge.conflictStyle = zdiff3. Maybe a bit opinionated, but it really makes proper merging a lot easier.
Ediff is still a GUI (yes, even if you're running emacs -nw).
I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
> Ediff is still a GUI (yes, even if you're running emacs -nw).
I'd dispute this, and more likely call it a TUI[0], unless of course one wants to go with the really pedantic point that all text is graphical.
It certainly isn't what I would associate with the words GUI merge editor, which feels to me more like what Sublime Merge for example does
> I also thing Ediff has some very annoying behaviors - the fact that it doesn't use intuitive names for the two buffers (especially because of Git's annoying nomenclature when rebasing vs merging), and the fact that there's no shortcut for inserting both the A and the B changes into the destination, which is a common operation.
Yeah, A, B, and C (and when doing the (z)diff3 thing, Ancestor) are certainly not the most intuitive names for the respective buggers (ours, theirs, result, and base in more Git-ish nomenclature) but it gets clear enough with practice. Not really a defence for bad UI, but eh, computer science is certainly known for that.
As for the "keep both" operation, yeah, that's lacking in ediff. There is one in SMerge mode (C-c ^ a) which of course activates when the buffer has any valid conflict markers, but at least in three-way merges, it also keeps the ancestor which is not usually what one wants.
Although at least when I was doing a lot of conflict resolution, a lot of the times it made sense to merge things by hand anyhow (it was a bunch of mega-merges related to a technology upgrade which had been half abandoned due to lack of time/focus from higher-ups), but I agree that the lack of "keep both" is problematic. Should probably file a bug report.
> I haven't really used the JetBrains merge UI, so I don't know if it's better or worse, but I don't think it's very hard to improve over ediff.
Probably not, but it also shouldn't be too difficult to improve on ediff either. And well, I at least like it better than the JetBrains resolution view or whatever VSCode has
I've seen another gui waaay back before git was popular. Perforce actually handled merge conflicts with a GUI just as good. I think it's still just as good, though almost no one uses it.
It works with git??? I had no idea. I highly recommend anyone reading this to try out P4merge as the merge conflict resolver for git. It might be the better alternative to jetbrains as jetbrains usually involves buying into using the entire editor.
> Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI
Not saying you are wrong, I used to only use VSC Gui for merge conflicts. Then at some point learned to edit myself and just use the CLI. After many many years I tried lazygit (TUI) for merge conflicts while still being in the terminal and I don’t think I can go back to do it manually anymore.
Graphical diffs that automatically handle merge conflicts visually with clicks to insert, undo and the ability for custom modification are MUCH MUCH more convenient with a GUI. Highly recommend the jetbrains conflict resolver gui.
I can assure you ANYONE who regularly has experience with both the CLI and that GUI(jetbrains) will hands down say the GUI is superior for merge conflicts. It is NOT intrinsic to the nature of merge conflicts. Any disagreement in this area stems from lack of experience or knowledge.
If anyone has experience with both and they have a contrary opinion, feel free to tell me. I doubt such a person exists though.