The problem is that source control is optimally a visual activity: the source control tree is a diagram, and the operations one does to it are diagrammatic.
Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.
Bothers me a lot that you're getting downvoted. Bunch of elitists who insist that cmdline is only way to get things done (everyone has to study cmdline options because who could possibly have multiple 4k screens for some visual options dialog?), probably using GDB in 2025 and having massive Stockholm syndrome about it, ...
I'm one of those folks who will tell people to give the official CLI frontend of git a chance and to try and stick to it. I can assure you it is not out of elitism, but experience. I've tried the many third party GUI frontends, and always got myself into bigger trouble down the line in the end, nor did they bring any of the revelatory boosts in insight they claimed they would. And of course, they're all a little different from one another, so migrating between them is an additional chore.
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.
GUI is absolutely easier for merge conflicts. I use the one that comes on jetbrain ides which is awesome.
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.
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 am sure you indeed do successfully use JetBrains to merge "the most massive conflicts". Good on you. I'm glad it works for you.
The mere fact you've even typed out the words "Anyone who has experience regularly(keyword) using both CLI and GUI for merge conflicts will side with me on this" makes you look like a child. This is how children speak.
>You probably worked with a trashy gui and likely didn’t use it too much.
You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Again, how hard is it to accept that people have different preferences? You are like those people on forums in the 2000s that argued that anyone that liked Ruby/Python was an idiot and obviously Python/Ruby was the far superior language. Anyone that disagreed obviously had never used Python/Ruby properly, and was obviously just a fanatic. I thought we moved past that stupid shit years ago.
> You don't seem to be able to encounter someone that disagrees with you without immediately assuming they must be doing something wrong, lack experience, or be stupid.
Yes. Not stupid though. More lack of experience. That’s my opinion about it and in my opinion the gui is better and that is a fact.
What I don’t understand is why my opinion about something as a fact no matter how extreme leads to you openly calling me a stupid fanatic and calling me a child?
I said you come off as stupider earlier with the additional statement of “not to be insulting”. I also said it to sort of illustrate to you and imitate you on what happens when you call someone stupid and then say the words “I don’t mean to be insulting” as if that negates what is in actuality an insult. It doesn’t and now you’ve openly called me a child. This ends here. Good day.
The community seems to disagree so far. I'll take a look at how it works tomorrow though. For me most of the misery around merge conflict resolution stems from how git fundamentally works, so I'm not sure how much it can possibly improve on it.
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.
This is basically my workflow too. I use git from the command line until I need to resolve a merge conflict, then I hop into vscode to resolve the conflicting file.
I don't consider myself a very core or talented developer, but I do feel quite strongly that git from the cmd line is much easier than a GUI, but overall ridiculously hard regardless. The abstractions and visualizations in graphical interfaces is either too dense & complicated, or more likely hides what's actually happening; there's no way to reduce the inherient complexity.
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.
NB. I did explicitly say a GUI on top of a cli app is a broken approach. Your intuition comes from this -- that the git API is cli-first.
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.
I thought I would be just fine with the CLI but I was amazed by magit. A GUI can work well if it leans into the strengths of GUIs - discoverability of features and showing state. Magit does all of these exceptionally well. It helps that git's CLI is quite poorly designed with a lot of unintuitively named commands. How do you undo a commit? How to unstage a file? What's a stash? What's the difference between log and reflog?
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.
The thing that CLI have over GUI is programmability, which for programmers is a valuable property. As for me, any repeatable task, I automate away with various degree of effort and quality. If I find myself needing a particular set of commands and flag, I create an alias, a function, or a shell script for that, like `flac2mp3.sh` instead of hunting down through the shell history.
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.
I work in a lot of repos at once. I do a lot of global search-and-replacing and random debugging. With SourceTree, I can easily see all the changes I've made across all repos in one glance.
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.
Which is kind of the point. If a GUI editor does this stuff for you, that seems like a win over incrementally learning these little command line tricks that save you a bunch of time.
That’s fine for some and I have no problems with it but my mind doesn’t work that way and instead it asked “how is possible the UI is doing this”. All of that lead to learning what hunks are and manually editing them to learn.
How does this scan a bunch of repos at once and let me see all the changes at a glance, and then drill down to individual files to either discard the changes (revert back to their committed state) or check them in?
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.
If "cd" and "git status" in a bash for loop is too advanced, you might need a GUI. Though I'd also argue that you've got too many separate git repos if you're finding yourself needing to do that often. It all depends on where you are on the journey to Monorepoland.
We're too small to implement a monorepo, because no one has time to build the tools we'd need to do it right. I still don't see what I gain by cd-ing into all those directories and running git status and looking at a bunch of text results, when I can just glance at the SourceTree repo window and see all the repos I've touched.
You're not offering any benefit that I'd get from using the command line over my current process, except, apparently, being able to express your superiority over GUI users.
I semi-agree - the real win is in unstaging changes you didn't mean to stage! Much easier in a GUI, because I don't have to remember the non-symmetric CLI command.
It bothers me a lot that you're complaining about downvotes when the comment you are replying to isn't even greyed out let alone flagged dead.
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...
There's a really good argument to use plaintext - it lends itself to very efficient use through searching, matching and replacing, whether interactively or in bulk. The lack of structure and semantics in a pure plaintext representation is often a curse, but sometimes a blessing.
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.
I learned the git CLI first, and still prefer it, but I've found VSCode's source control plugin very helpful for teaching newbies. I tell them to avoid the synch button and just manually git fetch/pull, but adding a commit is easier for a newbie to do visually.
I also found LazyGit recently and think that's a good middleground for doing things from the CLI.
If someone doesn’t use the CLI, they are a newbie? I’ve never needed to learn or use the CLI, the GitHub tools built into JetBrains IDEs and VS Code have always worked fine for me, and I’ve been a professional developer for nearly 30 years.
I think the idea is that the people you'd teach version control to are typically the newbies. You can also just be new to git specifically or the git workflow on any given project.
I love this book. It's what helped me move from an intermediate Git user to an advanced one, and I've subsequently trained a bunch of people at different organizations by going through it.
However, Pro Git is not an ideal resource for newbies unless they are highly motivated or receiving generous training. A simple graphical representation of your own repo goes a long way towards establishing a mental model of what Git is doing internally — which is in my view the chief insight of mjburgess's post at the top of this thread.
You’re probably right about that. I used a certain interactive online course when I was a beginner, but they’ve added “AI assistance for guided coding help”, so I hesitate to recommend it.
FWIW, the Git website links to some videos and external tutorials, which might be of use: https://git-scm.com/doc
Does not still fix the root cause that Git is super-bad as an industrial tool - actions that should be trivial push-button activities become incomprehensible command line character soup.
The fact there is a book on the subject speaks volumes about how bad it is.
If the existence of a book speaks volumes
about how bad something is or is not, I have some bad news for you about what's inside libraries. What beloved subject doesn't have a plethora of books written about it?
Exactly. VCS is part of an industrial process. It's not supposed to be implemented with a thin wrapper to a database whose node structure you need to rummage through.
The software analogue would be that in order to use the platform default List and Dictionary data structures you would need to manually manage the links between the data nodes.
Or to use text editor you would occasionally tweak the rope datastructure or equivalent. Etc.
VCS should be trivial push-button activity (and _is_ except with Git). There is no added value making a thing far less usable than could be. This is not git’s fault - it is what it is. But it is incomprehensible industry selected it as it’s de facto vcs.
All of them. A command line should not be the default option.
Again, this is not to bash Git. It's a bash on the industry for selecting tool that requires engineers to spend time and effort on non-value adding part of their work rather than offering a solution so simple you would most of the time not even think about it.
I use this whenever I need to look up anything outside of our workflow, but don't believe internalizing the myriad of git details has a very high pay-off. There's probably higher value knowledge in your role that you should prioritize.
The payoff comes when you develop a mental model of Git's data structure design, which is stuff like "a branch is a named pointer to a commit" and "the central data structure is a content-addressable store" — and most germane to this thread, "the source control tree is a diagram, and the operations one does to it are diagrammatic". (Thanks mjburgess!)
Learning Git's infinity CLI options won't teach you that.
1, Source control can get very gnarly when you have multiple editors on a codebase, and 2, good and comprehensive documentation for software is often many times longer than the software it documents. Man pages are a lot longer than -h
Which you can read easily in a week or two without much effort for something that is currently de facto for software development. The Emacs Manual has ~700 pages.
I'm not sure I entirely agree with this. I could see how this could be the case for newcomers to git, but after learning how git works through visual means, I think the mental model of how one should think of git is pretty simple (pleasantly simple, imo). Any complexity that comes from it may be due to how it is used (especially in a team setting).
The following command provides a visualization which is good enough to start from:
git log --oneline --graph
The more practical problem is that Github, which provides a useful graphic UI to complement the local command line for any project hosted there, is brain dead[1] about showing the source control tree as a tree and doesn't expose anything like `--graph`.
If you get tired of typing `git log --oneline --graph`, you can add a `git slog` alias[2] for it by adding the following in `~/.gitconfig`:
[alias]
slog = log --oneline --graph
[1] Gitlab is superior in this aspect, as it actually exposes a graph mode, via "[repo] > Code > Repository Graph".
`git log --graph` is just a really really bad GUI. Why not use a good GUI instead?
Although in fairness it's quite hard to find a good Git GUI because there are so many bad ones. The only good ones I've found all have some kind of flaw:
* GitX - the clearest design IMO, but it's one of those "gazillion forks" bits of software like TomatoUSB, and Mac only. Plus it has some annoying bugs.
* Git Extensions - I didn't even realise this was a Git GUI until relatively recently because it its terrible name. It's pretty decent, but Windows only.
* VSCode 'Git Graph' extension - my current favourite - it integrates into VSCode too which is much better than a standalone app, especially when using Remote SSH. However it is abandonware and although the source is available, the license doesn't let you republish it so it's not "open source" and nobody can take it over.
Disappointingly even these don't let you do things that a GUI obviously should let you do, like copy & pasting commits, dragging and dropping to rebase.
Like instead of `git rebase -i` and tedious text edits, why can't I just ctrl-select some commits, ctrl-C and ctrl-V?
But, they're still miles better than `git log --graph`.
Compare the graphs that people draw to explain git branching. They are usually very beautiful. Then you see the graph even these GUIs make, and they are still pretty bad. I think the visual graphs could be improved quite a lot.
`git log --graph` without `--oneline` is pretty hard to follow — that's not what I use, and it's not what I suggested.
With `--oneline`, it's not perfect but it's good enough to be useful — and by working within the constraints of the CLI, I didn't have to tell people to install software to get my point across.
And I already spoke approvingly of Gitlab's GUI for graph representation! I don't disapprove of GUIs; I use them all the time (particularly Github's). One you grok the data structures that underlie Git, you wind up seeing front ends as interchangeable.
Well, then I simply don’t agree that `git log --oneline --graph` is “really, really bad”.
Clunky? Sure, but it suffices to visualize simple branching patters. And no visualizer suffices for gnarly graphs (like a long-lived topic branch that has repeatedly merged in upstream), because the building a mental model of a complex history is difficult even if you can see it.
I basically never used Git command line unless fixing some problems other people created.
It is just insanity when people claim "only proper way is to use command line" - well yeah it is much faster if you work on your branch and just need to make quick series of commits. But as soon as you have to deal with collaboration with other people and organize project, coordinate features etc. I find GUI invaluable and Git Extensions of course.
No, I mean why can't you select commits in the graph and copy/paste them. I wasn't talking about copy/pasting the lines of text in the `git rebase -i` file.
It may serve a different purpose, but I personally use https://zolk3ri.name/cgit/ggrp/about/ for displaying commits, because it categorizes commits based on prefixes such as "feat:", "fix:" and so forth, and supports scopes too (e.g. "feat(foo)"), and a lot of my projects have commits with such prefixes.
Relied on gitk heavily when first started using git. People used to SVN and such will find git unfamiliar and scary.
Once I understood it as a series of revisions where even branches have little meaning, I never used gitk again…
The command line is actually very good if one gets in the habit of using something like “git log -oneline —reverse —no-merges origin/main..HEAD” to see where they are.
That's really it. Could I use the CLI? Sure. Do I? Nope. Using a tool like Git Extensions makes it so much easier to visualize what's going on. I have enough on my mind, I don't need to make the branch/merge/commit process harder than it is.
There are hundreds of them (everyone has an opinion about which is best). And most of them go out of their way to hide the nonsense that they have to jump through to get git to behave as the GUI expects it. Some of the visual git GUI tools do show you the gobbley-gook that they emit to the git CLI and it's shocking, like watching how the sausage is made.
Absolutely. Also graph and timeline view are invaluable for decades old projects when you are trying to find out when and why someone did some odd change.
Text-command-first approaches lead to inferior and hard to understand APIs which are, at best, papered over with a GUI. Managing the source of the project should be a series of trivial visual operations.