Comment by addicted | Hacker News Reader

Comment by addicted | Hacker News Reader

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.

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.

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

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.

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!

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

Reply on news.ycombinator.com