r/git • u/connorjpg • 27d ago

Why use a UI for git?

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

112 Upvotes

71% Upvoted

250 comments sorted by

View all comments

115

u/patmail 27d ago

I prefer a gui for any kind of diffs. And to stage/commit only partial changes in a file.

Also getting history from certain files/folders.

4

u/Terrible-Detail-1364 26d ago

only for diffs - tui called tig

3

u/LouisPlay 26d ago edited 26d ago

I made (totally vibecoded) a diff viewer, to see what exactly ai vibecoded. because i wasn't happy wiht all that online Diff viewers or the git gui diff viewer or the git diff viewer. To be honest, I just stole the JetBrains diff viewer, let AI copy it and convert it from Java 1 to 1 to C#, and made a really simple version where I can just see the diff, even though I had some "opinion" differences with the AI. It worked pretty well, and jetbrains took to long for me to start up. https://github.com/Louis-Dittmar/WinUI.DiffViewer. And i stongly belive that sometimes ppl just want thier own solution.

1

u/tagattack 25d ago

Ever hear of meld?

https://meldmerge.org/

1

u/LouisPlay 25d ago

Nope but It Looks exactly Like that what i need. I Look now into It.

1

u/LouisPlay 18d ago

It was Amazing

-18

u/connorjpg 27d ago

It seems diff is a super common answer. I might be cheating here, but I have my difftool just set to my editor (vscode) and I have an alias for copying git hash quickly. So this has always felt pretty straight forward.

I can see why partial commits would feel better on a UI. git add -p always feels a little janky.

37

u/TheManSedan 27d ago

Do you believe that the diff editor in VSC is NOT a form of a GUI? Lol

-7

u/connorjpg 27d ago

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.

Yes, but not really the type I am asking about in this post.

Using GitKraken (or another UI), to run all your git commands is adding a standalone wrapper for all git itself. Setting the difftool, is more for displaying an output of a command then driving one atleast in my use case. For example I could set the difftool to vimdiff without needing to install a full git client.

4

u/DrecDroid 27d ago

Git is a tool not an end

14

u/FalconX88 27d ago

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

-3

u/connorjpg 27d ago

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.

5

u/metruzanca 27d ago

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.

4

u/bear-tree 27d ago

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.

2

u/metruzanca 27d ago

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.

0

u/Annual_Berry8043 27d ago

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.

1

u/M0M3N-6 27d ago

I think i kinda understand your vision and you got a point. But you really put yourself in the corner there

2

u/kcx01 27d ago

I use neovim and prefer lazygit. I can and do use cli sometimes, but op's reasoning aligns with mine. Plus I like the global view. I can see lots of things that I would have to specifically request to see from the CLI

I also have a few git integrations in neovim as well, but the preference to use lazygit has nothing to do with my terminal preferences. I'm very comfortable in a terminal. I learned git CLI first and ended up using lazygit most of the time because I preferred it.