4 ms·
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, so
by sham1 2y ago
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.
- skinkestek 2y agoif I understand correctly ediff isn't cli, it is a gui built into emacs, only implemented unsing characters?
- tsimionescu 2y agoEdiff 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.
- sham1 2y ago> 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 [0]: <https://en.wikipedia.org/wiki/Text-based_user_interface https://en.wikipedia.org/wiki/Text-based_user_interface>