They said git-annex supports git back to 2.22. Not git after 2.22 was dropped.

An incompatible change in ghc would break compilation of other software also.

Looks like they are aware, and git-annex has been around for decades written by one of the best Haskellers. “Some guys hobby project” is not fair

How do you get your code to the point where it has no dependencies? How do you do any sort of database writing without a library, or web access without sockets from an os library?

What sort of code has no dependencies? I'm now very curious as I can't see how you can do anything without altest including the std lib from your OS to do any file i/o.

These days, my only deps are TinyUSB and LVGL - stuff that would be completely pointless and absurd to recreate.

I would be surprised if there is no LLM-assisted code in there prior to this commit, this is just the first where the author chose to disclose it.

LLM detection in writing is basically today's polygraph test pseudoscience. There was a blog a while ago where someone fed classic literature into one and it was detected as probably AI.

The sorts of folks who "won't be missed" put pedantry over productivity. To paint with a very broad brush, it's been my experience that they also tend to be stubborn and frustrating team members who don't understand that there's a time to debate and the rest of the time is for shipping.

A recent analysis on my Claude Code prompts showed 1.5B input tokens over the last few months. I use 4-5 provider agents (all CLI) DAILY, so this is a small subset. I spend a lot of time using transcription services to drone on about how some agent fucked things up and how I want it fixed and how to do it.

To assist with that process, I'm currently building out a search engine that is exposed via MCP to allow auditing of the dev runs. I already have the foundation of file changes (ala Splunk style) that let me keep an eye on the agents, and an agentic terminal that allows one agent to keep an eye on what the other agent is whacking on. Combined with my constant badgering for proper systems development, these things are improving the process at an acclerated rate.

Look, I get being an "engineer" on these types of things, and I think there is an absolute purity in pushing LLM generated code out of a codebase you control. That said, that's not the ONLY way to do things, and your milage will vary based on your systems thinking hat. I prefer to push hard on getting the outcomes and sacrifice the exhaustive process of reviewing every single line of code.

Consider frameworks. They make things easier to do, if they are complete and stable. There's an argument here that LLM harnesses should probably not ALSO be maintained by LLMs (something I'm completely ignoring so probably ironic I'm mentioning it). But the point being is the harnesses SHOULD have eyes on most lines of code. Eyes on every package though? Hard to say. I've settled on doing most stuff in Rust nowadays, just because it keeps the LLM more honest. And, we can build most "packages" by hand so we can change them to match our outcomes without code bloat. By bitching at it about code refactoring constantly, annealing the codebase by high level overview, not exhaustive review, I've found things get easier to work on as I go and still stay sane.

I do catch the LLMs occasionally hard coding things that belong in their own file or configs, and am a hardass about that and file length. I do read some code and hate it being overly long (and it sucks for burning tokens).

FWIW, I typed all this out on my keyboard myself. However, if I ran it through an LLM for cleanup or whatever, the very wall of text itself helps FORCE the LLM to stick to the substantive argument and steers it away from slop prompts. The same applies to code, if you are careful.