Hacker News Reader

> Then you’re maintaining a stack of patches on top of the upstream until the end of time

The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness:

  Set up a nightly cron job that
  executes the prompt: fetch upstream
  changes to the <software> and
  rebase all local changes on
  top of upstream. Check that the
  software works as intended and
  replace the current version.

That's not a solution, just the necessary work. You still have a stack of patches you continuously have to (have) rebase(d) on upstream.

That's why you only rebase when you actually need to in such cases. Another trick is to keep as few touch points into the original code as possible, preferring to keep most custom code in custom files.

There are software tools like quilt, who do exactly that.

Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue.

But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you.

e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spent a week of getting LLMs to build my own solid pty/terminal emulator. Now I have my own and frankly I'm in a better position having done it.

That's a ridiculously massive change to our relationship with software projects.

I too built a terminal emulator and I like it, but I wouldn't say it's easy to maintain even with LLMs. The # of edge cases is insane.

The cool thing is that you can use and adapt the tests of all major third party terminal implementations. Come up with your own invariants (brainstorm them with a smart LLM), and now every third-party test either passes, diverges (due to invariant/arch), or diverges (due to product bug).

And even if you aren't that robust about it, terminal apps are the sort of ideal vibe-coded app since, using it daily, you are giving it a constant real world test that uncovers issues to be fixed incrementally.

Is neovim over tmux over ssh glitching? LLM can fix it.

Is codex or claude code overwriting lines in the TUI, maybe due to alt screen, but it also happens in other major terminal apps? LLM can figure out why and whether you can come up with better general architecture to fix it.

Is there behavior you wish you had but no other terminal app supports? LLM can add it.

You can end up with a far better product than what you would find in the wild, and it's a fun sort of work.

> Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date.

I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.

StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.

Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.

It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.

> even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support

It seems like a great stretch to call this "slop".

I agree but it’s their project and their rules. To them I’m just another guy tossing slop over the fence they don’t have time to review in the hig stack of all the other slop.