For example: https://andrewaylett.github.io/rgitweb/ is a repository viewer that runs against a static git repo. It doesn't care what you're storing the pack in, just that the data is there to make the right range requests.

All the sources of randomness are under the control of the provider, even if today's deployment structures mean providers introduce extra randomness due to the concurrent nature of the evaluation. Serialise the computation, feed it from a pRNG, and you have a fully deterministic result. But providers don't want to offer a deterministic result, and especially not one as fragile, expensive, and inefficient as a full serialisation would be.

†: For variants of "nothing" that include cost and deployment challenges.

Where LLMs can be really actually quite useful, is situations where you have a lot of context and want to distil it. That's what I think happened here: the author has a lot of information to convey, and the LLM-generated output is relatively information-dense.

Unfortunately there's no objective measure for information density of an arbitrary piece of text.

[1]: https://taginfo.openstreetmap.org/keys/official_name#overvie...

I'm certainly not saying you should use this code, but it's a proof of concept for avoiding the CPU overhead of cgit rendering by loading the data on the client.

It cost me £8.27 of Fable use (from the free credits I've been given) and 56% of my five hour quota on a $20/month Pro plan. There's no server logic, it's 1.3MB of minified JS and CSS and (while I'm absolutely not suggesting anyone try to use it) it basically works: https://github.com/andrewaylett/rgitweb

This is a one-shot, my prompt set the expectation that I'd be able to load resources using CORS but (not entirely unreasonably) the Git hosts I've tried don't set CORS headers.

Shared more because I was pleasantly surprised at how cheap and easy this was -- and with a repo link because talking about it without sharing the link would be a bit crass.

Given one of the major themes of the leave campaign was "restoring parliamentary sovereignty", it's darkly ironic that leave also campaigned against parliament actually using that sovereignty, and indeed came closer than anyone else (including the EU) to restricting parliamentary sovereignty.

Ebikes are pedal assist, power limited, and limited to only assist up to a certain speed. You can go as fast as you're able, but if you're above (commonly) 25km/h the motor won't help you. They're allowed anywhere you're allowed a non-assisted bicycle.

Electric motorbikes may be limited by the manufacturer in order to achieve a certain license class, but once you get past the low power classes, they're only as limited as their petrol cousins. They're only allowed on roads.

Any middle ground, including things that look like bicycles but don't require the rider to peddle, fall either into the "electric motorbike" category or into the "not roadworthy" category. Riding them without a proper license, insurance, and equipment is illegal.

Somewhat unfortunately, much of the press seems to want to class the non-roadworthy motorised vehicles as a special case of "ebike" rather than the general case of "motorbike".

(And to your first point: yes there are speed limits but it's fairly common for cars and motorbikes to be able to go much faster than the limit. In first gear, even, for motorbikes.)

It's not the LLM that spammed, it's the people who set up the LLM.

And the implementation feels very much like it sits in the UI layer, rather than further down the stack.

I'm not trying to claim stacking PRs in this way is the best way (it's not). But it does add an extra affordance for those who want it without burdening those who don't with the need to understand why someone would prefer it.

And there are also plenty of ways that people have been working around GitHub's (and to a lesser extent, git's) lack of tooling for working on changes in this way. I'm sure they have customers clamouring for the feature; whether they'll be happy with what they get remains to be seen.

(Very happy jujutsu user here, my tooling makes it really easy to create stacked commits with a stable identifier that maps really easily to branches and then onwards to running `gh stack`, but what GitHub have delivered is definitely still lacking)

A set of stacked PRs is exactly the same as a line of commits. The only difference is the UI, but the UI is the important bit here because lack of UI is what's stopping folk from doing that today.

Even when I've developed my changes as a stack of commits, I'll feed them to my team one commit (and one PR) at a time so they're easier to review — and I discovered that GitHub had turned on stacked commits UI because for one particular project I'd manually created a set of PRs in advance (with the right bases) and GitHub offered to create a stack out of them.

Edit: which also means you're not wrong, if you've got claims that trigger damage control then HR are even less your friend.

The people within HR may be friendly, they've probably got friends :). It can be a very people-oriented role. But they are incapable of being your friend when you're interacting with them in their role as representative for the company.

I greatly appreciate my employer's HR folk, they're really lovely, very good at their jobs, and want to help. But if I have to have a formal meeting with them, I would definitely bring along my union rep.

Or at least they were, until I started using cache components the other week, and I'd not noticed they'd regressed. That's frustrating. Give me a few minutes...