Comment

Comment on What helps people get comfortable on the command line?

liliumstar@lemmy.dbzer0.com ⁨1⁩ ⁨year⁩ ago

That’s a good article. From my observation, there are a few things:

Necessity. I’m active in communities with people who don’t use the terminal until it’s an absolute necessity. Like people running unraid, docker, or whatever containerized server. Eventually they need to type commands.
The prettiness. Yeah, I run oh-my-zsh. It’s nice having a setup pretty environment. Some people’s only experience might be opening up the powershell default display to run one command… And that is a bad experience.
Niche commands/programs. Take ffmpeg as an example. It’s probably the most powerful media tool that exists, but has no official gui. And it’s expansive enough that no GUI really covers what it can do. There are a bunch of other things like this.

source

Sort:hotnew top

StudioLE@programming.dev ⁨1⁩ ⁨year⁩ ago
You’ve never used a graphical git client?!

I’m comfortable on the command line but a decent git UI is a way better experience.

git diff is so basic using a GUI makes it far easier to compare changes.

Same for merge conflicts. I’m not sure you can even resolve them on the CLI?

Any form of rebase: I think I used the CLI to do an interactive rebase a few times in the early days but I’d never do so without a GUI now.

Managing branches: perhaps I’m a little too ott but I keep a lot of branches preserved locally, a GUI provides a decent tree structure for them whereas I assume on the command line I’d just get a long list.

Managing stashes: unless you just want to apply latest stash (which admittedly is almost always the case) then I’d much rather check what I’m applying through a GUI first.

There are some things I still use the CLI for though:

git remote add git remote set-url because I’m just too lazy to figure out how to do that in a GUI. It’s usually hidden away somewhere.

git push --force because every GUI makes it such an effort. C’mon! I know what I’m doing - it’s /probably/ not going to mess things up…

source
- atheken@programming.dev ⁨1⁩ ⁨year⁩ ago
  I use git on the CLI exclusively. I almost never rebase, but otherwise get by with about 5-10 commands. One that will totally change your experience is git add -p
  
  source
  - StudioLE@programming.dev ⁨1⁩ ⁨year⁩ ago
    
    -p –patch
    
    Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.
    
    This effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.
    
    The documentation is entirely meaningless? What does it do?
    
    source
    atheken@programming.dev ⁨1⁩ ⁨year⁩ ago
    You can stage individual chunks of a file.
    
    Useful if you have a large set of changes you want to make separate commits for. I also just find that it’s a good way to do a review of each chunk before committing changes blindly.
    
    Give it a shot some time, worst case is you stage some stuff that you don’t want to commit, but it’s non-destructive.
    
    source