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.
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.
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.
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.
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
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.