I don't know why so many devs avoid a GUI for Git

https://twitter.com/hanspagel/status/1729639520713261311

by keybits • 3 years ago

24 47 3 years ago

palata2• 3 years ago

Simple: it's a preference. I go for CLI over GUI whenever I can. Some people go for a GUI whenever they can. And some people (way too many IMO) just go for whatever "seems to just work" and doesn't require them to learn how to use correctly.

thegrim33• 3 years ago

The question is WHY it's your preference. The tweet argues that it's "better" to use a GUI. Do you agree or disagree? Obviously you disagree, or else you wouldn't use the CLI (I'd imagine). If you disagree, then it's not "just a preference", you have a reason for it. What's that reason?

palata2• 3 years ago

Hmm I respectfully disagree :-).

"Blue is the best color" is a preference. I am perfectly entitled to say "Nope, in my view, Red is the best color" without justifying. I just like red better.

I like minimalism, and a CLI tool is always more minimal than a GUI one. Also I like doing stuff with my keyboard, and the CLI is perfect for that. GUI tools usually require a mouse, and that is not ergonomic for me (but ergonomic is personal, again).

bakioka• 3 years ago

I prefer a gui and use magit in emacs. But everytime I ask someone they act offended that I'd even think they'd use a GUI instead of the CLI. I really really like gitkraken as well but I wouldn't pay for that.

BillyTheMage2• 3 years ago

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.

eviks2• 3 years 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

BillyTheMage2• 3 years ago

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

rcxdude• 3 years 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• 3 years 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• 3 years 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.

klysm• 3 years ago

Because I know exactly what the CLI commands do, the work anywhere on anybody’s machine, and I don’t know what a GUI is actually going to execute

sublinear• 3 years ago

I completely agree with this. It's also way faster, more flexible, and scriptable. What's the point of getting used to a substitute that's a worse implementation of a restricted subset of the original?

As soon as the mouse cursor or having to scan my eyes across the screen is involved in any way I'm being forced to waste more time looking at less information. The fatigue of using GUIs adds up tremendously in the course of a day. I suspect the people who prefer them aren't aware of this. There's likely a negative health correlation with GUIs (eye strain, back problems, etc).

jmarchello• 3 years ago

I’ve been primarily using lazygit and man is it nice. It’s perfect for typical workflow stuff (pulling/pushing, branching, even conflict resolution). Occasionally I’ll reach for the command line for more advanced tasks though. There’s just more fine-grained control with the cli tool.

crzylune• 3 years ago

This feels like a stealthy advertisement for a git client that requires an annual subscription.

rjst01• 3 years ago

100% agree with this. Personally I've been using SourceTree since before it was acquired by Atlassian. It's such a powerful tool because it instantly gives you a level of situational awareness that would take several commands to get from the command line.

I usually still make commits from the command line, but then review them in SourceTree before pushing. I also find it to be a much more straightforward interface for doing an interactive rebase.

Looking for a replacement has been on my to-do list for a while however, as Atlassian has kinda been letting it lagnuish.

russianryebread• 3 years ago

Fork[1] could be considered a drop-in replacement (both visually and functionally) for SourceTree. It does, however, fix SourceTree’s biggest warts, and is much more stable.

I’m not affiliated with them, just a satisfied customer.

[1] https://fork.dev

eviks2• 3 years ago

Switched from ST to Sublime Merge for its great context-dependent single-button UI navigation any app should have (thought it's not default) like switching tabs or changing a file selection within a tab to views a diff

ThalesX2• 3 years ago

I really like Visual Studio Code's Git integration. Both the default one and the GitHub extension that really helps with PR reviews.

I've paired with devs that use CLI and it feels like they're in the stone age, especially when doing merge operations, but, at the end of the day, to each his own.

jcparkyn2• 3 years ago

Have you tried GitLens? It's the first extension I install after I install vscode, and it expands the built-in functionality by about an order of magnitude (although I'm not super happy about the shift to paid features in recent years).

ThalesX2• 3 years ago

Yeah. GitLens and GitHub Pull Requests and Issues are awesome. Prettier is also a close second.

jwells89• 3 years ago

I prefer GUIs simply because they let me see several things at once with a window split up into panes without having to multiplex or tile terminals.

It can’t just be any UI though, that I’m particular about. My favorite used to be the native GitHub client for Mac, but when GitHub abandoned that and replaced it with a much worse cross platform app I switched to Fork[0] which has been excellent and even has a native Windows counterpart. Sublime Merge[1] is also nice but doesn’t gel as well with how I think.

[0] https://git-fork.com/ [1]: https://www.sublimemerge.com/

addicted• 3 years ago

I don’t avoid a GUI. I just use it for what I find it efficient (complicated diffs and merges, complicated history, etc) but use the CLI for other stuff I find the CLI more efficient for (simple history lookups, diffs, merges, staging changes, commits, cherry-picks, rebases, bisect, etc).

There are many reasons why the CLI is far more efficient for me for this.

1. I’m rarely ever just doing GIT operations in isolation. Depending on the kind of project there’s a whole lot of other stuff going on as well…builds, unit tests, etc… I can’t run that out of Git Tower. But I can run all of those from within the same CLI environment.

2. I can never modify the way GIT tower presents information to me. However, I have a lot of tools to isolate exactly the information I want using git on the CLI where it makes sense because the CLI allows me to compose GIT outputs with an extremely large library of tools in a way no GUI application does.

3. I love scripting. If I do the same action more than a few times I will write a script for it. And the CLI allows me to do that in a way GUI tools don’t.

eternityforest2• 3 years ago

I do pretty much the opposite, using the CLI only for stuff that the GUI can't do.

I can click a file I want to review faster and easier than I can type the name, and Git Cola's diffs are easier to read than default black and white CLI diffs.

maegul• 3 years ago

This is where I landed. CLI for power user mode.

bravetraveler3• 3 years ago

The CLI lets me find the file once and pass it between things pretty much endlessly

A magic var: "$_"

I made another post in this thread about it... I'm tired/on mobile, so apologies if I'm terse.

tldr: get in the habit of arranging the file to be the last argument. Subsequent use is entirely free

Or, really, anything you want to pass around. Not just files.

smusamashah• 3 years ago

Intellij has built in Git GUI which has lots of features of other commercial dedicated tools. Features I use include selecting and committing individual lines where needed, rearranging and squashing commits all within easy ui.

okr• 3 years ago

Interestingly i also do not use it and still prefer CLI, while the rest of intellij is my daily driver.

It almost seems like, i have a model of git in my head and these GUIs have another model in mind. And it does not match.

JCharante• 3 years ago

Avoiding using a mouse whenever possible helps prevent injury

1letterunixname3• 3 years ago

Logitech G604 cries in bluetooth and takes its toys home.

Also, a HumanScale 6G 500 keyboard tray because few tables are ever at the correct height.

wolpoli• 3 years ago

I currently use a Git GUI (SourceTree) because I used to use a GUI when working with TFS, CVS, and SVN. So when we switched to Git, the CLI paradigm just seem unfamiliar to me.

prepend• 3 years ago

It’s faster to use the cli. I don’t know why any dev wouldn’t understand this.

Bnichs• 3 years ago

Intillij Git branches is the only git ui I've used and I love it for one feature: it stores your workspace layout based on the branch you're in. So now when I go to an old branch every tab I was working on is there in the configuration I left it. This prevents from having too many tabs and helps keep them organized.

Still, for every other git function I find the cli and ctrl-r much quicker.

theogravity• 3 years ago

I use it for rebasing, cherry-picking, and conflict resolution. I'm a visual person so it really helps.

genpfault• 3 years ago

Sadly TortoiseGit[1] is only available for Windows :(

git-cola[2] is a decent stand-in for TG's commit review window though.

[1] https://tortoisegit.org/

[2] https://git-cola.github.io/

pulpfictional• 3 years ago

Emacs has Magit which is great.

1letterunixname3• 3 years ago

In general, the primary values a gui has over a cli:

0. Visually demonstrate proposed intended behavior unfamiliar to the user.

1. Visually select desired operation behavior interactively.

2. Gradual disclose features and teach a cli from a gui tool.

A good git gui should continually display cli equivalents, log cli-equivalents of operations performed, or allow visual commits, rebases, cherrypicks, merges, branches, etc.

GhostVII• 3 years ago

For me at least I do all of my development on the command line, so it's just much easier to use the git CLI instead of switching between applications. And regardless, basically all the commands I run (moving between commits and rebasing, mainly) can be done just as fast or faster with the CLI, with the added benefit of being able to see and retrieve your command history to easily redo actions.

I kind of have the opposite question - what benefit does a GUI have for git? If your tree gets super complex I get how a GUI makes it easier to navigate, but if you only have a couple branches it seems easy enough to just view in terminal.

zingerlio• 3 years ago

TUIs are somewhere in between. I like lazygit.

MarkSweep• 3 years ago

I’m surprised no one here is mentioning the two GUI programs distributed with Git: gitk and git-gui. Just type “git gui” in a repo to bring it up. The biggest thing I like to do with git-gui is staging individual lines from the working copy into the index. This is possible with “git add -i”, but this is one place where a GUI is much more pleasant.

gitk takes similar arguments as “git log” or “git rev-list” does. It’s a pretty ok way to view commit history.

Both of these are kinda quirky tk/tcl programs. But they are available on cross platform, so I only have to learn one GUI for Linux, Windows, and macOS (though the macOS support is the most likely to be broken).

deafpolygon• 3 years ago

Historically, git gui programs were often incomplete. You still had to drop into a shell to do some work. Often, gui VCS were also not-git. Finally, there's this culture of "oh, you use a gui for git? you must not understand the tool."

Am4TIfIsER0ppos• 3 years ago

59 eurobucks *EVERY YEAR* to use a free program (git). Not to mention it doesn't support what git was written for (linux).

renecito• 3 years ago

"I don't know...", nah, it's more like you don't care.

I don't know why so many devs avoid a GUI for Git

Related Stories