atheken

Yeah, -p can help with that. I’m not much for “commit grooming” - as long as a branch merges to main cleanly and passes tests, I don’t care about an “ugly” commit history.

I think this is an important lesson in general, and one that applies in other contexts:

You don't need a "cheatsheet" for most stuff. The things you do all the time will become muscle memory, and the other stuff is easy enough to look up as it's needed.

You don't need to memorize the entire class structure of your projects. The "hot paths" get the most attention, and you'll remember the most critical stuff as you work in a codebase. There's lots of code that is basically "dark matter" - we know it's there, and it's doing something, but because we rarely review/modify it, it's only important to understand its observable effects, not the precise way that it works.

Your brain is basically like an LRU cache - the stuff that you touch a lot will stay loaded, and the stuff that you rarely use will get dropped. Embrace this property.

I’m not sure if you’re being funny, but of course committing the output of your program isn’t what I was saying.

That’s fine until a UI changes, or the steps to reproduce it are incomplete (or a human doesn’t follow them exactly).

Text commands are unambiguous and precise.

There are other reasons to use it. A major one is doing a “code review” of changes before committing, or even deciding to drop a chunk of code from a commit entirely (like a debug statement that no longer is necessary.)

I’m all about frequent commits (and right-sized commits), but the functionality can still be beneficial even in those scenarios.

I also don’t care if I have a broken commit. This turns up very quickly, and there is zero expectation that feature branches are always in a working/stable state. The expectation is that pending work gets off the local machine on a regular interval.

They basically aren’t?

If you’re doing one-off hobbyist stuff, maybe.

But literally anything in a professional setting should be in text that can be committed and searched in a source code repository. If you can’t commit it to git, it didn’t happen.

Cue the first post about the exploit that leads to leaking AWS keys. I’ll wait.

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.

I’ve had ohmyzsh installed for years. TBH, I still don’t know what it gives me over bash. In your experience, what is the “killer feature” of zsh?

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

I also have my diff/mergetool configured to use kaleidoscope, but still do everything else in the CLI.

I think you’ll have better luck with podcasts. Technical books tend to have long tracts of code that would be excruciating to listen to.

You might enjoy:

• co-recursive
• software unscripted
• this developer’s life

I read The Phoenix Project recently, and had a PTSD episode from all of the hallmarks of dysfunction that I’ve experienced in my career. Good book, but probably needs a trigger warning.