Then of course it's possible I didn't give the many GUI frontends enough of a chance. Such is life, it's a resource limited game. Principally, I justify my position with the argument that the many GUIs will try to translate git into something visual by adding their own designs, and this can prove additionally misleading and difficult, if git wasn't rough enough already.
The only GUI bits I use for git are editor integrations such as the official one in VS Code, and only when I know it's adequate. Which you can only know if you know what's going on in the background.
This isn't even opinion. It's fact. Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this by an overwhelming majority such that I might as well call this fact.
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.
For some reason there are a lot of subpar uis though. E.g. not showing three versions, only showing THEIRS and not the remote branch name, etc.
It's still free, too.
I actually use Difftastic on the command-line for diffs and spit out to P4Merge for merges.
Here's my Jujutsu config:
[ui]
diff.tool = ["difft", "--color=always", "--display=side-by-side-show-both", "$left", "$right"]
merge-editor = ["/Applications/p4merge.app/Contents/MacOS/p4merge", "-nl", "Theirs", "-nb", "Base", "-nr", "Mine", "$base", "$left", "$right", "$output" ]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.
My point is, is this TUI considered graphical?
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.
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.
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>
I honestly don't mean to insult you but when you say things like this in a discussion where others obviously disagree with you, it makes you seem like either an overly enthusiastic beginner that hasn't learnt about tradeoffs yet, or a very stupid fanatic. You might be neither, but that is how it comes across.
>Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this
I and many others simply disagree with you. I have used those tools. They work okay in simple cases but break down in more complex ones. That is my opinion.
I would say that my opinion is shared by the overwhelming majority in such an overwhelming way that it’s indistinguishable from fact.
My take: don't play the game. learn your basic required workflow from the command line and use the decent documentation to look up everything else.
Source control should be designed graphically first, with a cli to automate. I routinely use tree-view and column view in macos finder to think-through fs organisation -- doing this as a sequence of cli commands would be masochistic.
Notice how all the best vcs tutorials are just providing basic visuals which would be better as the interface.
For most vcs tutorial, they don't often use why the history of changes is important, instead focusing on a set of usual commands. Why, not how. Once you have that philosophy down, the tool usage become much more efficient.
With magit I've been able to do things I wouldn't bother before, like reverting small parts of hunks from past commits, doing partial staging of files (not including all changes), and dealing with stashes effectively.
I can then drill down to each file with the visual diff and see whether the changes are something I want to check in, or just debugging. If it's debugging code, I can click "Discard Changes" to drop all changes I've made to that file. Or I can selectively discard a hunk or discard lines.
When I show these features to command line purists, they always concede that this can't easily be done with the command line. So I don't see what's to gain if I'm losing those features, which I rely on constantly.
I've been working in SourceTree for a decade, so I know all the quirks by now, which I pass on to any new devs who want to use it.
git add -p
?All git add -p does is that last part from what I can tell. I'd still have to cd into each repo and run git status one by one (I've made changes to up to 10 repos before for one tweak), and then do a git add -p to the changes I do want, and a git stash to the changes I don't and then delete the stash.
Scrolling through changes and staging lines is just much nicer with a mouse.
It bothers me a lot that you can't discuss something like this without turning it into personal attacks. People can't just have different preferences than you. No it has to be "elitists" with "stockholm syndrome". This kind of rhetoric is unbecoming of this forum and destroys amicable discussion.
Have you considered that maybe people use the command line because it is better for them, and they recommend it to others because in their view, you'll need it eventually so why not learn now?
You can visualise a git history with a gui tool while still learning the command line interface btw. They aren't mutually exclusive. Do you just use scratch too? Or are you one of those elitists using textual programming languages? Must be stockholm syndrome...
At the same time, I'll go further than you, GP and GGP - I'd say that insisting on coding in plaintext, specifically on always directly reading and editing the same plaintext, single-source-of-truth representation of a program, is fundamentally limiting our ability to manage complexity, and makes people waste a lot of time on faux-problems like "lots of small vs. few big functions", or "exceptions vs. result types", etc.
FWIW, plaintext is still okay for most coding use cases - it's trying to fit everything into the same source code and somehow keep it readable that's an impossibility.