Kind of feels like "crypto is a type of currency and not all cryptography", or "SQL Server is a specific product of Microsoft".

Wonder if how it happened this time was people read the specs and explanations of WebAuthn, saw "passkey", never seen that word before and assumed it's only ever been used in the super narrow context of WebAuthn so it can only mean that. Maybe "header" can only ever mean "HTTP header".

Thinking about it like that, it may be more like how "latte" is specifically espresso with milk (it's really just milk), or "queso" is specifically cheese dip (it's really just cheese of any kind), or "masa" is specifically made of corn (it's really just dough of any kind, or it's mass like atomic mass is masa atómica).

As to

> No major bank revokes your password when you setup a passkey, either.

If we're talking about requiring 2FA via TOTP or challenge-response hardware tokens or banking apps implementing such, that depends on the country. It's the status-quo in some places. Some banks even put the input field for the token output as a third input in the login form on their website because all customers have them. The rest separate their login form in multiple steps, but they likely require it of all customers too.

With the exception of Github, and banks.

(Depending on what the PR's about and how the team organizes. Ideally, there's consensus on the goals or who's responsible for what. Reviews can be limited to finding bugs and e.g. organizational problems)

  man git-bisect

  git checkout @~ ^tests

> commits around it to figure out why that change was even made.

A commit should be such that the message can articulate the why.

Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.

EDIT: Yeah, this seems to be it. `git branch b` on b, then `git rebase -i --update-ref @~3` from main caused branch ref `b` to move from d86229e to 02fcaf7:

  * 1e354fb (HEAD -> main) fix b
  * 40e6f70 c
  * 02fcaf7 (b) b
  | * f4188e0 (branched-feature) d
  | * d86229e b
  |/  
  * 5fe78fa a

`git tag -f` to move a tag.

Personally, I just do `git show` when I'm feeling cautious, but I can generally just scroll up to find the last `git commit` I did with the hash in the output. `git reflog` should also have record of it, so everything else is kind of extra.

Can't, because a commit's hash takes into account the parent hashes.

Haven't used --update-refs, but reading it, it should result in your third graph. So,

> is there a way to get `git rebase` to have the same behavior?

is already the case.

`git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

With stories, probably. With nonstories, and depending on what kind of nonstory book, I might jump around a lot. I might like to skim quickly (e.g. chapters/sections, starting sentences of every few paragraphs, etc.), then skim more thoroughly (e.g. recheck paragraphs of a chapter to get a general flow of it and how they connect, etc.), then read thoroughly on some sections and less others. You just can't do that with audiobooks. You don't have the same level of control.

Depending on how thought-provoking something is, my mind may stray on thinking of implications. Then, it's easier for my eyes to dart back by the time I notice and reread x or y, than rewinding, listening a little bit, rewind some more, etc. I might just stare at some words sometimes. You can't stare at sound.

Memory in relation to sight and sound is probably different, too. With sight you can kind of make more associations. You read an idea, and you can associate that with the location of where you're reading it (what part of the page, around how many pages have been turned in the chapter, what chapter, thickness of pages on left and right side of the spine). With sound, it's just a single stream. You're not staring at the timestamp location in the file of everything you're hearing and there isn't like this hierarchical location structure.

Almost nobody is on a static IP. ISPs have an interest to keep their customers connected and not affected by other customers, so they'd probably use as large address pools as possible for their dynamic IP rotations. "Did something bad once" is short-lived unless address ranges are large.

Tech companies like Google are interested in being global monopolies to dominate markets and also having as good and large-sampled statistical data as possible from everyone. Blocking thousands of users for each bad user that can likely easily switch to another block if they really want to doesn't seem effective. It would also affect their reputation. Who wants to rely on an email service that may block you because of other users on your IP block? Having a reputation for being reliable is important for businesses.

With small personal sites/blogs like the ones you mentioned, they can just block most of the planet without a problem. There's not as much reason to be as reachable as possible (some may be satisfied with an audience of a handful of people), and they're also more budget conscious.

In the case of Google blocking an Apple service, they not blocking users; they're blocking Apple. The users can just not use Apple's service.

Places with open WiFi like hotels and restaurants would be having the same problem. People on CGNATs would be having the same problem. An IP doesn't correspond with a single user.