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