Live data from Hacker News

Bluesky migrates to single-tenant SQLite

github.com

41–50 of 247 posts

Re: Bluesky migrates to single-tenant SQLite

#41
post #29

Earlier quoted context omitted.

I prefer to read the unified diff and commits don't matter as much.

don't know why, but recent teams around me have always made strict rules about number of commits in PRs. I just wanted to tell them the same thing you said: "Why don't you just look at the diffs?" curious for other opinions. (sorry not really about this particular topic)

I prefer to have clear commits that tell a tidy story. For example:

* Refactor function `foo` to accept a second parameter

* Add function `bar`

* Use `bar` and `foo` in component `Baz` to implement feature #X

If you give me a commit history like this, I can easily validate that each step in your claimed process does what you describe.

If you instead give me a messy history and ask me to read the diff, you might know that the change to file `Something.ts` on line 125 was conceptually part of the refactor to `foo`, but I'll have to piece that together myself. It's not obvious to the person who didn't write the code what the purpose of any given change was supposed to be.

This isn't a huge deal if your team's process is such that each step above is a PR on its own, but if your PRs are at the coarseness of a full feature, it's helpful to break down the sub-steps into smaller (but sane and readable) diffs.

Re: Bluesky migrates to single-tenant SQLite

#42
post #8
post #3

I am curious, does the HN folks know if bluesky is more active than nostr or the mastodon network?

Less active than Mastodon, I'd assume more active than Nostr. But the interesting thing for me isn't activity — it's the people on there. Of the cohort who had >100k followers on Twitter, I think more of them post regularly on Bluesky than post on Mastodon. Bluesky definitely has a more cohesive feel, especially because there's currently just one instance & mod team.

Mastodon, and the Fediverse in general, make user interaction decisions on purpose to limit many of the issues common to social media. Think about: mob culture, addiction, and the like.

I wonder if BlueSky intends to follow on those. For example, hiding user actions counts (repeats, favourites, etc...) until the user acts on one.

Things like these may be strange for those accustumed to Twitter, but personally, is what makes me stick with smaller instances on the Fediverse.

Re: Bluesky migrates to single-tenant SQLite

#43
post #29

Earlier quoted context omitted.

I prefer to read the unified diff and commits don't matter as much.

don't know why, but recent teams around me have always made strict rules about number of commits in PRs. I just wanted to tell them the same thing you said: "Why don't you just look at the diffs?" curious for other opinions. (sorry not really about this particular topic)

A good practice is to rebase your commits before creating a PR into a single commit. You are free to commit as many times as you want to while doing your work. This minimizes the noise in the log.

Re: Bluesky migrates to single-tenant SQLite

#45
post #29

That looks like the PR from hell - 190 files changed, 143 commits? Mostly with names like "tidy" and "wip" Props to whoever actually reviewed that, you are a warrior

I prefer to read the unified diff and commits don't matter as much.

Same. Do whatever you want in your feature branch, what matters is the Files list and the description in the PR. The whole thing gets squashed into a single commit anyway (which also makes reverting much easier).

Re: Bluesky migrates to single-tenant SQLite

#46
post #29

Earlier quoted context omitted.

I prefer to read the unified diff and commits don't matter as much.

Commit your code and commit it often. There's no reason not to.

Unless you’d like to maintain your train of thought.

I don’t want to interrupt my flow with intermediary commits.

Re: Bluesky migrates to single-tenant SQLite

#47
post #8
post #3

I am curious, does the HN folks know if bluesky is more active than nostr or the mastodon network?

Less active than Mastodon, I'd assume more active than Nostr. But the interesting thing for me isn't activity — it's the people on there. Of the cohort who had >100k followers on Twitter, I think more of them post regularly on Bluesky than post on Mastodon. Bluesky definitely has a more cohesive feel, especially because there's currently just one instance & mod team.

I'm a donating supporter of the Mathstodon.xyz instance, but (sadly?) most of "math Twitter", at least the education-focused university faculty, ended up on BlueSky. I think there's a strong appeal for "a straight forward Twitter clone without Musk" for a lot of people.

Re: Bluesky migrates to single-tenant SQLite

#48

Earlier quoted context omitted.

don't know why, but recent teams around me have always made strict rules about number of commits in PRs. I just wanted to tell them the same thing you said: "Why don't you just look at the diffs?" curious for other opinions. (sorry not really about this particular topic)

I prefer to have clear commits that tell a tidy story. For example: * Refactor function `foo` to accept a second parameter * Add function `bar` * Use `bar` and `foo` in component `Baz` to implement feature #X If you give me a commit history like this, I can easily validate that each step in your claimed process does what you describe. If you instead give me a messy history and ask me to read the diff, you might know…

This is reasonable, but the problem I encounter is how stifling it seems to ask others to structure their work so specifically. By way of comparison, getting compliance on conventional commit messages is a challenge, and that's an appreciably smaller ask than this.

Re: Bluesky migrates to single-tenant SQLite

#49
post #29

Earlier quoted context omitted.

I prefer to read the unified diff and commits don't matter as much.

Commit your code and commit it often. There's no reason not to.

Sure, but then there's nothing wrong with rebasing it and making a nicer story for other people that want to review it.

Diffs are great but sometimes they're just as overwhelming in a huge PR. It's nice to first follow 5-10 commits in chunks of logical change.

Post reply on HN