3 ms·

Some people prefer CLI over GUI, me included. For a lot of us, GUI is really inefficient compared to keyboard-centric interfaces. You have to move your hand awa

Some people prefer CLI over GUI, me included. For a lot of us, GUI is really inefficient compared to keyboard-centric interfaces. You have to move your hand away from the keyboard for every little thing you want to do. I see it as analogous to the difference between spinning disks and solid state drives; one is better in almost every way, the other only has like one advantage for a subset of people. I also recommend against using git GUI for beginners just because it hides so much of what's going on, making it easy for people to stop learning after they figure out how to do exactly 2 things with it: commit and push. But honestly if we're going for "best" I think magit is the winner.

eviks 3y ago
This is a faulty comparison, GUI can be even more keyboard-centric than a cli as there's no conflict with the terminal host and shortcut support is richer
- BillyTheMage 3y ago
  You're right, I guess I just hate the mouse. Should've changed my comment to TUI>GUI instead of CLI>GUI.
rcxdude 3y ago
Hiding stuff is probably the main reason why I think the git CLI interface is not so good: it's much, much harder to learn what's going on without a good view of the commit graph, and while you can extract that from the CLI it's not something that is obvious to beginners, and it's tedious for more experienced use. Also, the mouse will generally beat the keyboard for selection tasks, which is a decent amount of git usage. Splitting up changes in your working directory into multiple commits is substantially faster with a GUI, as well as a lot of commit graph manipulation options.
SOLAR_FIELDS 3y ago
I mostly agree. My day to day workflow often relies on the CLI for the reasons you mentioned. But I will race you in resolving complicated merge conflicts in the CLI while I do it with jetbrains 3 window conflict editor. That thing is insanely good to the point that I will sometimes literally install and only open jetbrains product just to use that feature. Imo CLI is just historically bad at merge conflicts in general which kind of sucks because it’s a pretty common thing to have merge conflicts in any reasonably busy repo. A couple other things the CLI sucks at: - Complicated staging of chunks of files - Complicated interactive rebase
IlliOnato 3y ago
The GUI I use (weirdly called "Git Extensions") does not hide the underlining commands: when you perform an operation it presents you with a dialog that shows the command line. You can inspect them, copy the command text, or cancel the operation if the command does not look right to you. For some operations it's more that one command, so you are present with more than one dialog. For me it's not just a convenience, but a learning tool about more obscure Git operations and their parameters. Several times when I found the documentation obscure I would just make Git Extensions generate a command, and it helped me to understand a command -- or discover one. Having said that, I find Git command-line interface hard to memorize and not very consistent/logical, so I prefer to use the GUI when possible. And you cannot beat it for partial commits or resets.

eviks 3y ago

This is a faulty comparison, GUI can be even more keyboard-centric than a cli as there's no conflict with the terminal host and shortcut support is richer

BillyTheMage 3y ago
You're right, I guess I just hate the mouse. Should've changed my comment to TUI>GUI instead of CLI>GUI.

rcxdude 3y ago

Hiding stuff is probably the main reason why I think the git CLI interface is not so good: it's much, much harder to learn what's going on without a good view of the commit graph, and while you can extract that from the CLI it's not something that is obvious to beginners, and it's tedious for more experienced use. Also, the mouse will generally beat the keyboard for selection tasks, which is a decent amount of git usage. Splitting up changes in your working directory into multiple commits is substantially faster with a GUI, as well as a lot of commit graph manipulation options.

SOLAR_FIELDS 3y ago

I mostly agree. My day to day workflow often relies on the CLI for the reasons you mentioned. But I will race you in resolving complicated merge conflicts in the CLI while I do it with jetbrains 3 window conflict editor. That thing is insanely good to the point that I will sometimes literally install and only open jetbrains product just to use that feature. Imo CLI is just historically bad at merge conflicts in general which kind of sucks because it’s a pretty common thing to have merge conflicts in any reasonably busy repo. A couple other things the CLI sucks at: - Complicated staging of chunks of files - Complicated interactive rebase

IlliOnato 3y ago

The GUI I use (weirdly called "Git Extensions") does not hide the underlining commands: when you perform an operation it presents you with a dialog that shows the command line. You can inspect them, copy the command text, or cancel the operation if the command does not look right to you. For some operations it's more that one command, so you are present with more than one dialog. For me it's not just a convenience, but a learning tool about more obscure Git operations and their parameters. Several times when I found the documentation obscure I would just make Git Extensions generate a command, and it helped me to understand a command -- or discover one. Having said that, I find Git command-line interface hard to memorize and not very consistent/logical, so I prefer to use the GUI when possible. And you cannot beat it for partial commits or resets.