HNHacker News
TopNewBestAskShowJobs

yrotslluf

6 karma · joined February 5, 2025

submissionscomments
yrotslluf··on Ask HN: How to be alone?
Despite the comments bickering about how often to hit the gym or what types of activities overlap -- this comment is right: hit the gym.

Get a personal trainer or try signing up with a CrossFit gym or another gym that has coached classes. You need form instruction, and you need to take it slow.

For me, my mental health and physical health are tied directly to each other and this was the single best thing I did for myself in my late 30s.

yrotslluf··on Show HN: I was reintroduced to computers: Raspberry Pi
Thinking through the stated use case makes me think a small drone that would undock, scan your house, send you the video, and redock on request would be a useful project/product. Great peace of mind without a full stationary security camera system.
yrotslluf··on Beej's Guide to Git
Not wrong of course — thank you for your amazing guides! But feedback re: "15.7 Multiple Conflicts in the Rebase":

There are two things I suggest as workflows for people when I teach them about rebase workflows.

> Since rebase “replays” your commits onto the new base one at a time, each replay is a merge conflict opportunity. This means that as you rebase, you might have to resolve multiple conflicts one after another. ... This is why you can conclude a merge with a simple commit, but ...

For multiple conflicts on several commits being replayed, if it's _not_ useful to go through them all one at a time, I suggest that people do a squash first rebase from the fork point (which by definition can not have conflicts) to collapse their commits into a single commit first, and then rebase again from the branch.

For instance, if forked from main:

    git rebase -i `git merge-base main --fork-point`
Squash all of those, and then as usual:

    git rebase -i main
Second, when rebasing repeatedly onto an evolving branch over time, you'll often find yourself resolving the same merge conflicts over and over again.

"rerere" (https://git-scm.com/book/en/v2/Git-Tools-Rerere) will allow git to "reuse recorded resolution" so that you don't have to do them manually each time.

My gitconfig for these:

    [alias]
     forked = "!f() { git merge-base $1 --fork-point; }; f"
     squash-first = "!f() { git rebase -i `git merge-base $1 --fork-point`; }; f"
    [rerere]
     enabled = true