`git update-server-info` is your friend; it generates the auxiliary files needed to allow clients to make range requests against packs.
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.
LLMs are inherently deterministic. The way everyone deploys LLMs leads to non-deterministic results, but there's nothing† stopping providers from offering deterministic evaluation if they choose.
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.
This is technically true, but when people talk about randomness, its not only about same input-> different output, like temperature>0 and the things you said.
Its also about very similar inputs -> different outputs. Even with everything you said, yes, same input would result consistently into same output, but sliightly different input and you might get completely different/semantic answer.
In my mind, slop is when the output is longer than the context provided by the user -- there's text, but there's no content.
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.
It seems that there are 363,123 `official_name:` tags in OSM [1], and the discussion thread hints that at least some* of them are due to naming disputes. Given (according to the thread) no-one actually renders the tag on their maps, using that tag in this case seems like a good policy.
Just for fun, because I could, I vibed up a `cgit` replacement that runs entirely in the browser -- point it at a git repo where you've run `git update-server-info` and it'll load files as if it's starting to clone the repo, using range requests and browser caching to avoid actually loading more data than necessary for the view you've requested.
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.
Which was, procedurally, the correct course of action: the referendum was non-binding, because the UK's constitution only allows for non-binding referendums. Parliament is sovereign, whether you and I like it or not (and I'm generally ambivalent about it).
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.
I wouldn't call it ironic. The forces behind Leave were - still are - far-right nationalists and wannabe autocrats. They consider democracy an annoyance - ideally a temporary one.
Their idea of sovereignty is telling everyone else what to do. They wrap this up in flags and Sptifire biscuit tin patriotism for the poorly educated, but it's all for show.
What they want is unlimited power over others. The EU has always been an obstacle to that.
The different nationalists - the Republicans in the US, the Putinists in Russia, the Zionists in Israel, the Brexiters in the UK, the Saudi oil imperialists - are all tentacles of the same creature, and more likely to cooperate with each other against their native populations than act independently.
There's a big difference between an "ebike" and an electric motorbike.
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.)
They don't. But reviewing individual commits in the GitHub UI is hard.
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.
> They don't. But reviewing individual commits in the GitHub UI is hard.
So instead of solving that problem, GitHub developed tooling around a workaround for that problem (targeting a PR at another branch that also has a PR).
Expanding reviews to allow per-commit reviews avoids the need for managing additional branches and all the headache that comes with it.
Indeed. But lots of people have never even heard of Gerrit :P.
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)
I’m a pretty clean committee. About every graphite stack I’ve worked on for the past 2years has been single commit per PR. The tooling managing all the rebasing and PR bases is great.
The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.
The approach that GitHub chose can show those people almost immediate benefits, which is surely the better path towards adoption than trying to reeducate everyone to adopt a development flow based on clean rebases.
And for those of us who do prefer clean rebases, the thing they built is still useful.
A bunch of details aside, the major conceptual thing that the email based flow has which is still missing in GitHub's data model is the ability to have a discussion on the stack as a whole.
> The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges.
We couldn't organise our commits once the PR review started because reviewers would complain they couldn't easily determine what had changed between rounds of reviews.
If we tried to organise them after review then approvals would be stripped so squash was the only way we could keep the main line history reasonably tidy as you can keep the approvals if GitHub does the squash via the UI.
Even if the people working in HR genuinely want to do the right thing for the employees, and company policies support them doing that, interactions with HR are inherently adversarial.
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.
Entirely this. When you are interacting with HR, that person on the other side is trying to protect the company from whatever claims you are about to make.
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.
reply