Mine's this-ish (nushell, but easily bashified or pwshd) for finding all merged, including squashed:

    let t = "origin/dev"; git for-each-ref refs/heads/ --format="%(refname:short)" | lines | where {|b| $b !~ 'dev' and (git merge-tree --write-tree $t $b | lines | first) == (git rev-parse $"($t)^{tree}") }

Does a 3-way in-mem merge against (in my case) dev. If there's code in the branch that isn't in the target it won't show up.

Pipe right to deletion if brave, or to a choice-thingy if prudent :)

More likely the town of Os in Innlandet, Norway, which was around that population a year or two ago.

Very good! I didn't think of towns. I established that the alpha-2 country code "OS" is unassigned, and went hunting through the smallest microstates.

https://datatracker.ietf.org/doc/html/rfc6996#section-5 - it's in the range reserved for private use, so it's probably network internal to wherever the list is originally from?

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it.

  <button form="logout-form" ...>logout</button>
  <form name="logout-form"></form>

No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

doable but rarely used, inconvenient and awkward, alex proposes allowing buttons to be stand-alone hypermedia controls which also allows multiple buttons located within a form to perform different actions (e.g. save v. cancel)

Oh for sure, standalone elements would definitely be better, I just wanted to point out that there's a way around needing to do silly stuff like <form class=blabla>

Though in my experience, it's great in frameworks like svelte. Define your forms at the top of the component, and you can see at a glance what native actions the component can do, and where it posts to.