I don't know why so many devs avoid a GUI for Git(twitter.com)
twitter.com
I don't know why so many devs avoid a GUI for Git
https://twitter.com/hanspagel/status/1729639520713261311
48 comments
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.
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.
This is where I landed. CLI for power user mode.
Alias the most common operations and sequence of operations, and alias git to g. Cli productivity is generally higher than clicking around a gui for all but complicated operations.
I'm no git CLI expert, but I would humbly disagree with that. I keep a "git changes" view open most of the time in vscode, so most common operations are literally either one click or one hotkey away.
Complicated options are really the only thing I'd consider faster in the CLI, simply because they don't exist in most GUIs.
E.g.:
- Stage/unstage a file in one click.
- Stage/unstage/revert a line or block with select+hotkey.
- Switch between editor and (editable) diff with one hotkey, and another to toggle between inline and side-by-side view.
- Focus the commit message box with hotkey, type message, ctrl+enter to commit.
- Hotkey or command palette to switch branch, then search for branch name.
- Blame for current line always visible.
- Commit list, file history, or line history can be focused with a single command from the palette (or hotkey if I could be bothered memorising it).
- Easily view stashes and apply all or part of them in a couple of clicks.
- Open any git ref in a new vscode window (not editable), without needing a separate checkout or modifying the current one.
- Easily view commits on other branches and cherry pick/merge/rebase at will.
Complicated options are really the only thing I'd consider faster in the CLI, simply because they don't exist in most GUIs.
E.g.:
- Stage/unstage a file in one click.
- Stage/unstage/revert a line or block with select+hotkey.
- Switch between editor and (editable) diff with one hotkey, and another to toggle between inline and side-by-side view.
- Focus the commit message box with hotkey, type message, ctrl+enter to commit.
- Hotkey or command palette to switch branch, then search for branch name.
- Blame for current line always visible.
- Commit list, file history, or line history can be focused with a single command from the palette (or hotkey if I could be bothered memorising it).
- Easily view stashes and apply all or part of them in a couple of clicks.
- Open any git ref in a new vscode window (not editable), without needing a separate checkout or modifying the current one.
- Easily view commits on other branches and cherry pick/merge/rebase at will.
Yea - this. With the CLI, I often don't have to pick a file at all.
I've likely just backgrounded or closed some other reference to the file: 'vim', 'pylint', etc.
The shell makes subsequent references basically free with this: '$_'
I've internalized this as "the last arg to the last thing I ran". It probably has some esoteric meaning to BASH...
Point being: if one plans the placement of their args they stop having to think about finding files or tabbing to exhaustion.
This works with anything you'd give as an argument
I've likely just backgrounded or closed some other reference to the file: 'vim', 'pylint', etc.
The shell makes subsequent references basically free with this: '$_'
I've internalized this as "the last arg to the last thing I ran". It probably has some esoteric meaning to BASH...
Point being: if one plans the placement of their args they stop having to think about finding files or tabbing to exhaustion.
This works with anything you'd give as an argument
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.
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.
That's pretty cool actually, never heard of that one before!
Seems more suited for smaller projects than larger ones, usually I'm always jumping between HTML template, server code, JS, browser, and some badly documented library I suspect is buggy.
I don't often do multiple different things in a row to one file, but for those times I do this will probably double or triple my speed.
Thanks for making us all aware of it!
Seems more suited for smaller projects than larger ones, usually I'm always jumping between HTML template, server code, JS, browser, and some badly documented library I suspect is buggy.
I don't often do multiple different things in a row to one file, but for those times I do this will probably double or triple my speed.
Thanks for making us all aware of it!
Happy to share!
This sequence is more regular with multiplexed terminals - one window, many panes.
Many people like 'tmux'. I ended up stuck with my terminal handling it (Kitty)... I learned this way first.
Anyway, if I'm iterating a lot on something, I end up using two or three panes at least.
One pane as the ringer/wildcard while others are more static - an editor, the interpreter, etc.
Reserving the 'ringer' pane protects that last argument for quick use. This reservation is aided by having the other static panes for my editor and such
This sequence is more regular with multiplexed terminals - one window, many panes.
Many people like 'tmux'. I ended up stuck with my terminal handling it (Kitty)... I learned this way first.
Anyway, if I'm iterating a lot on something, I end up using two or three panes at least.
One pane as the ringer/wildcard while others are more static - an editor, the interpreter, etc.
Reserving the 'ringer' pane protects that last argument for quick use. This reservation is aided by having the other static panes for my editor and such
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
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).
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).
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.
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.
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.
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.
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
You're right, I guess I just hate the mouse. Should've changed my comment to TUI>GUI instead of CLI>GUI.
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.
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.
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
A couple other things the CLI sucks at:
- Complicated staging of chunks of files - Complicated interactive rebase
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.
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?
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).
"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).
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/
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/
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).
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).
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.
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.
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.
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.
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.
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.
Still, for every other git function I find the cli and ctrl-r much quicker.
I use it for rebasing, cherry-picking, and conflict resolution. I'm a visual person so it really helps.
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.
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.
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).
Yeah. GitLens and GitHub Pull Requests and Issues are awesome. Prettier is also a close second.
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.
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.
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.
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.
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.
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.
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
I’m not affiliated with them, just a satisfied customer.
[1] https://fork.dev
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
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/
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/
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."
This feels like a stealthy advertisement for a git client that requires an annual subscription.
Emacs has Magit which is great.
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.
59 eurobucks *EVERY YEAR* to use a free program (git). Not to mention it doesn't support what git was written for (linux).
TUIs are somewhere in between. I like lazygit.
"I don't know...", nah, it's more like you don't care.
It’s faster to use the cli. I don’t know why any dev wouldn’t understand this.
Avoiding using a mouse whenever possible helps prevent injury
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.
Also, a HumanScale 6G 500 keyboard tray because few tables are ever at the correct height.
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.