#microformats 2026-11-03

2026-11-03 UTC
#
gRegor jtojnar: I'm confused by the #292 PR and the subsequent ones. It sounds like you split them up, which sounds good, but #294 for example still seems to have a mix of things, like the mock server, not just removal of the unused function.
[Morgan_M], [tw2113] and jtojnar joined the channel
#
jtojnar gRegor It is a stack of atomic commits (see e.g. https://hamy.xyz/blog/2025-07_stacked-commits)
#
jtojnar some of the commits depend on each other so each PR includes the previous PRs in the stack
#
jtojnar once the bottom of the stack is merged (ideally using --ff-only to keep the history clean and linear), it should disappear from the PRs higher in the stack
#
jtojnar I am using gh-stack tool to rebase the commits but unfortunately, it currently does not support stacked PRs coming from forks: https://github.com/github/gh-stack/issues/46
#
jtojnar you can see the overview of the stack in https://github.com/microformats/php-mf2/pull/292#issuecomment-6574620138
[Murray], [KevinMarks], barnaby, jtojnar and vriska_ joined the channel
#
wturrell I feel bad about asking this (so I've waited a long time)… but *why* is microformats.org so slow? Connectivity? What it's sharing the server with? Some MediaWiki issue? Would money solve it? I can't help but think maybe we'd have greater adoption if it was consistently fast. (Also, I'm generally using it to look at popular pages I'd assume would be cached.)
#
aaronpk It's mediawiki getting slammed by crawlers and isn't yet behind cloudflare
#
aaronpk And cloudflare isn't even the whole solution because the crawlers are stupid and they continually traverse every diff page going back forever so there's effectively unlimited pages for them to crawl and that doesn't cache well
#
ulhar4409 putting diffs behind a login could probably help? although i'm not familiar with what logging into their wiki looks like
#
aaronpk yes, that's what i did for the indieweb wiki. but there's no built in way to do that in mediawiki so it takes extra nginx config and login needs to happen via nginx too
jtojnar joined the channel
#
wturrell aaronpk: thanks.
barnaby and [pfefferle] joined the channel
#
[pfefferle] @jtojnar you can also rebase the pr to the branch it depends on. This way the follow up does not have to include all the same changes.
#
[pfefferle] Wenn the one branch is merged and deleted GitHub should automatically rebase the follow up one to the main branch.
#
gRegor Yeah, I mainly use the github.com merge tools, so not sure stacked commits are going to work
#
[snarfed] github added native stacked commits recently!
#
gRegor interesting. I still don't really get it in this scenario. like type hints don't depend on adding a mock server.
[Leo], [aciccarello] and jtojnar joined the channel
#
jtojnar [pfefferle] that is already the case, later PRs are superset of the previous ones
#
jtojnar though GitHub will not do any rebasing by itself, nor recalculate the list of commits (unless they fixed it recently)
#
jtojnar gRegor I needed the mock server since testing the type change without it was unbearably slow
#
jtojnar I could probably drop it now but there is some overlap in the code so I would need to resolve the conflict
#
jtojnar I can do that if you prefer
[Al_Abut] joined the channel
#
jtojnar [snarfed] the GitHub stacked commits currently do not seem to be applicable when the PRs’ head branch is in a different repo from the base branch so not usable with forks
#
[snarfed] jtojnar hmm that's surprising, I kind of doubt that. PRs from forks are the common case
#
[snarfed] I don't see that restriction mentioned on https://docs.github.com/en/pull-requests/get-started/about-stacked-prs . may just be a new feature and they're still rolling it out
#
jtojnar [snarfed] https://github.com/github/gh-stack/issues/46
#
Loqi [preview] [zygoloid] #46 FR: support for cross-fork stacked PRs
#
[snarfed] oh wow, ok!
#
[snarfed] they claimed they'll do it, and that it's high priority, back in April, hrm
#
jtojnar I think it was intended for enterprise users
#
jtojnar for projects I have commit access to, I usually prefer creating branches like wip/jtojnar/foobar in the main repo anyway, so stacked PRs work there
#
jtojnar but I would like it if external contributors could use this feature too
#
[snarfed] let's take it to #indieweb-random
barnaby and jtojnar joined the channel