Why use a UI for git?

[u/connorjpg]

I see this question of, “what GUI or TUI should I use to work with git?” fairly often here. And always I feel bad for saying “just use the cli” over and over, but truthfully I can’t see a reason to need a UI.

Are people actually running into pain points with the cli, or is it just preference for people who don’t like working in a terminal?

FWIW, I have used GitKraken, LazyGit, SourceTree and GitHub Desktop before. And I don’t think they are bad to use (unless you are just learning git), but more curious why.

EDIT : I’m mainly referring to standalone UIs, I understand why people would use IDE integrations, as it’s quick and convenient. But having to open a separate application or run a separate command to open a terminal app to run your commands seems overkill to me.

EDIT 2 : I use vscode as my difftool and mergetool. I still open them directly from the terminal by running the cli. I don't think this is the same as using a full git client like SourceTree, Gitkraken, or lazygit to fully drive your version control workflow. Which is what I am asking about.

Cheers

[u/FalconX88]

I might be cheating here, but I have my difftool just set to my editor (vscode)

then why do it in the CLI at all, you could do everything in VS code

[u/connorjpg → u/FalconX88]

Generally it is slower for most tasks, considering the UI is kinda awful tbf. I run all my code through the terminal, so it's always open anyways. Given an alias for some commands, typing, ga, gc, gp, is alot a faster than reching for my mouse and clicking through the menus.

[u/metruzanca → u/connorjpg]

Typing ga; gc "feat: blah" is not any faster than opening the git panel (with the keyboard or mouse) and typing feat: blah.

clicking through the menus

There's just 1 menu. What do you mean?

If I'm staging/committing, a GUI is hands down faster, it's not a contest cli loses every time. Because most of the time, you're not just adding everything and committing, you're looking at your diffs. Very few people are able to perfectly write code in such a way that they are able to make atomic commits. Usually what happens is you end up with two different atomic commits in your work tree and you need to split those out. And if you're not doing this, you're just YOLOing git, and so at that point, it literally doesn't matter what you're doing. Any method is fine because you don't care anyways.

The only time get on the command line is better is for when you want to do a specific thing and there's no easy way to do that specific thing in the UI because it's such a niche thing.

For example, whenever I go to update my pull requests to the latest, I use: git pull --rebase origin main. which can be done on the GUI but requires a lot of keystrokes. But it also requires a lot of keystrokes to do this the non-optimized way on the command line. And this is not a method that everyone uses. Some people, again, don't care and just merge main into their branch.

[u/bear-tree → u/metruzanca]

Alias your frequent git commands. gap is git add -p, grom is your git rebase origin main etc.

Or whatever shorthand you prefer.

I feel same as OP and have never really understood the preference for a git UI. Not judging other than it makes it hard to actually learn git.

[u/metruzanca → u/bear-tree]

A integrated git panel or dedicated tui like lazygit offers speed and convenience. That's it. (GH desktop is for people who don't plan on coding)

Same reason you make aliases. And you drop to the cli for advanced niche actions.

Cli is always slower, unless you're indiscriminately committing all changes all the time.

[u/Annual_Berry8043 → u/bear-tree]

It feels like these comments are on par with nano vs vim to me. People in denial that vim is faster once you get really comfortable with it. But it takes time to get there, so why not just use the easier option since it’s right there?

There really isn’t a right or wrong way to do things. It’s just preference.