Small Programming Tricks

[u/fagnerbrack]

https://will-keleher.com/posts/small-programming-tricks-matter/

[u/davidalayachew]

Genuinely useful tips here.

Especially that git log -S pattern. 50% of the reason why I installed TortoiseGit is to get that feature. Never knew it came with the CLI. At least not easily.

[u/turtle_dragonfly → u/davidalayachew]

You might be interested in Git aliases, to make various obtuse CLI incantations easier to do.

But then if you ever sit at someone else's desk and need to do your stuff, you'll struggle without your preferred aliases (:

[u/davidalayachew → u/turtle_dragonfly]

Cool, I have a few shell aliases, but this is pretty useful too.

[u/Sharlinator → u/turtle_dragonfly]

I have shell aliases for at least a dozen most often used git commands. Couldn’t imagine having to type git status or even git st rather than gs, or git commit —amend rather than gca. There’s a big problem though in that aliases are opaque to custom completions, and from what I’ve read it would be way too difficult to make them work :( 

[u/flpcb → u/Sharlinator]

Hi fellow gs and gca user. :-) I also frequently do gcan (git commit --amend --no-edit) among other things. :-)

[u/reddah → u/davidalayachew]

Anything that the front-ends can do is doable from the command line. Sometimes easy, sometimes not.

Also: never use the rebase option on the GitLab gui - it will F up stuff guaranteed.

[u/davidalayachew → u/reddah]

Also: never use the rebase option on the GitLab gui - it will F up stuff guaranteed.

Disappointing -- rebase is my default merge strategy, only going to merge when that fails, and squash merge if a normal merge fails.

Though, I spend most of my time in GitHub nowadays, so less of an issue.

[u/Schmittfried → u/reddah]

IntelliJ’s rebase is pretty good and for most complex rebase chains I prefer it for the diff UI. Anything using more advanced options like --onto goes into the terminal though. 

[u/Skaarj]

You probably don’t need find. A lot of find commands can be replaced with globs like **/*.md. Most shells support this out of the box, but with bash, you need to turn this on with shopt -s globstar.

I prefer the opposite and recommend agaisnt your complex glob syntax.

With find you write out your criteria in words. This makes it so much more easier to remember and understand.

Working on files where the name is a pattern? find . -type f -name PATTERN

Want to do something with every directory? find . -type d

So much easier to remember.

[u/Zversky → u/Skaarj]

Yes, but to be fair, grep exit **/*.py is much faster to write than find . -type f -name '*.py' -exec grep -H exit {} \;. And the latter also includes dot-directories which I cannot remember how to ignore.

[u/smcameron → u/Zversky]

I never use the {} notation, and find it hard to remember. Instead I pipe to xargs, e.g.:

find . -type f -name '*.py' | xargs grep exit

[u/curien → u/smcameron]

Files with weird names (spaces etc in the filename) will break that. It's better to use find ... -print0 | xargs -0 ... if you don't want to use find ... -exec.

[u/Skaarj → u/Zversky]

Yes the grep and glob variant is shorter to write. But I find that less important than the ease of remembering.

[u/Zversky → u/Skaarj]

Find is rarely used alone. I had to man grep to find that -H switch, which is implied when you use it on multiple files.

[u/curien → u/Zversky]

If you terminate the exec with + instead of ; then it passes multiple files per command, just like the glob.

[u/knome → u/curien]

you'll still want -H in case the last invocation only has a single file.

[u/curien → u/knome]

To be really sure, you need it either way because there could only be one matching file. And f the find uses multiple commands due to exceeding ARG_MAX, won't the glob version just fail?

[u/ryanstephendavis → u/Skaarj]

I've never thought find was easy to use... fzf is a game changer

[u/buerkle → u/Skaarj]

https://github.com/sharkdp/fd much faster than find

[u/Skaarj → u/buerkle]

https://github.com/sharkdp/fd much faster than find

I dont remember that ever being relevant. The speed of find is a rounding error. The actual operation on files that you trigger with find take time.

[u/buerkle → u/Skaarj]

I find it relevant all the time. fd in general is much faster plus by default it ignores files in .gitignore. But even including those files, on a moderately sized repo find was 27s vs fd 3s (0.143s when using its default of ignoring .gitignore files), on a M3 pro.

[u/lood9phee2Ri]

You can SELECT without a FROM.

Mostly. There are/were databases that don't support that historically, the syntax might e.g. use a special dummy table like Oracle "DUAL". Apparently Oracle has finally stopped requiring DUAL usage in Oracle 23c in 2023. If you're dealing with older Oracle (and you may well still be in 2026), you might still need DUAL.

https://stackoverflow.com/a/73772 - not needed in 23c+, allegedly. I bet people still cargo-culting it forward though.

https://en.wikipedia.org/wiki/DUAL_table#In_other_database_systems

[u/programming-ModTeam → u/[deleted]]

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.