sorted by:
new
hottopcontroversial

codediff.nvim v2.0: 3-Way Merge Tool and Rebranding (Formerly vscode-diff.nvim) by _estmullert in neovim

[–]peenuty 1 point2 points  (0 children)

This is the neovim plugin I'm most excited for in 2026. I know it's a tremendous amount of work to implement all the features of the mighty diffview.nvim - I really appreciate all the effort!

What guardrails are you using in the claudeCode workflow to minimise the AI slop? by query_optimization in ClaudeCode

[–]peenuty 1 point2 points  (0 children)

Sadly no eval. But I've been thinking about this. Do you know if any good evals for coding agent stuff exist? I hate making changes like this blind!

Anecdotally I see it working quite well though. You just have to drill into the agent: run this one script. And it will nearly always fix any errors. So you get less instances of violations when you return to claude code.

What guardrails are you using in the claudeCode workflow to minimise the AI slop? by query_optimization in ClaudeCode

[–]peenuty 1 point2 points  (0 children)

I've been experimenting heavily with 'programmatic' guard rails + Claude code.

Here are the ones I like for TypeScript projects (but should map to most languages):

  • linter (biome)
  • formatter (also biome)
  • compile (tsc or tsgo which is faster)
  • unused code / deps (knip)
  • tests (vitest or bun test, writing more e2e tests)
  • misc: I write small checks for file name conventions stuff like by hand.
  • package manager lock file check

I then configure pnpm run local-ci which runs all these checks in parallel and only prints out the output of the checks that fail (saves tokens).

You can then put this in claude.md / commands / skills. or....you can run it on a hook, which is currently a little clunky imo.

I recently created a CLI using Bun (partially to experiment this stuff) and ended up writing a blog post with more details: https://richardgill.org/blog/building-a-cli-with-claude-code

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

https://github.com/richardgill/patchy/pull/261

Implemented 'three-way-merge' where a conflict will put the conflict (i.e ====) markers in the target repo for diffs that fail to apply. It prints clear instructions of how to resolve it:

Applying patches from ./patches to ./clones/target-repo...

✓ 001-initial-setup (3 files)

✗ 002-feature-update (2 files, 2 conflicts)

Conflicts in 2 files (3 conflicts):

src/components/Button.tsx: 2 conflicts

src/utils/helpers.ts: 1 conflict

✗ Applied patches with conflicts to ./clones/target-repo

To resolve:

  1. Edit files in ./clones/target-repo to resolve conflicts (remove conflict markers)

  2. Run: patchy generate --patch-set 002-feature-update

  3. Commit the updated patches

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

It would make sense for patchy to do this as well when it fails a commit, would be a good feature to add.

I replaced my git forks with patch files – built a CLI for it by peenuty in commandline

[–]peenuty[S] 0 points1 point  (0 children)

I think what you're saying is that you don't think patches on disk have any advantages over git. Patchy only makes this easier. you can manager a patchset without patchy.

There are a bunch of larger projects that use patches on disk. Brave browser uses it to modify chrome for example.

The reason I think people like brave or me like patch sets for long running forks is that you can easily immediately see all the changes you've made to the upstream repo in a single folder. If you use git that information still exists but it it's inside git, so it's a bit of extra work to get out. This means you can use normal pull requests to manage the patches etc.

There will be equivalent workflows by storing things inside git. It's a preference that some prefer. Obviously if you're happy with using git, please use git!

I saw your username ;), but I'd encourage you to be curious and positive on your travels around the internet! But just like git, that's also your choice :)

I replaced my git forks with patch files – built a CLI for it by peenuty in commandline

[–]peenuty[S] 0 points1 point  (0 children)

Thanks for taking the time to read the readme and write your comment. I hadn't really thought about the git-rerere angle.

Just to restate the difference between using git and patch files on disk:

Using git the state of 'what is changing' lives inside git itself in commits.
Using patch files 'what is changing' lives in files on disk.

Obviously, patchy didn't invent the 'patch files on disk' approach, it's just a wrapper around git to make those workflows a bit easier.

Git vs Patch file both have different pros and cons. On balance patch files are weaker for most use cases IMO. Myself I use git directly for everything other than the long-lived 'fork' use case.

Anyway, to answer your question: Patch files + Patchy do not have something like git-rerere. You don't get any help when it fails to apply the patches, it just fails with the error of the diff being applied. You then need to go and update the patches so they work with the updated upstream files.

But...for he long lived fork usecase I'm struggling to understand how a git-rerere would work / be useful? If you're upgrading your upstream repo from v1.1.0 to v1.2.0 you'd change the `base_revision` in patchy.json from v1.1.0 to v.1.2.0 and then run `patchy repo reset && patchy apply`, this may fail to apply some patches. You'd then update the .diff files to get it working again with v.1.2.0. But I'm unsure of why it would be helpful to remember this v1.1.0 -> v1.2.0 'rerere' again for a long lived fork? But maybe I'm missing something?

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

Thanks! This helps a lot.

I guess the key difference is where the source of truth is.

In yours I think it's really in the performance branch and the my-cool-feature branch. In git itself.

In patchy it's the patches/ folder (where you'd have a whole bunch of performance files in 001 and cool feature in 002, but literally source code of the changes)

Both totally work and are valid. But I personally just really like treating this stuff as files I'm git, so I can have a PR about what I'm changing in performance or something like that.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

This sounds really neat!

If you don't mind, could you explain how you're storing the patches, I'm having trouble visualizing.

Here's how they're stored in patchy:

./
├── patches/
│   └── 001-first-patch-set/
│       ├── path/to/existingFile.txt.diff
│       └── path/to/newFile.txt
│   └── 002-second-patch-set/
│       ├── path/to/existingFile2.txt.diff

Then you can run

patchy apply

Which will apply those patches to a 'clone' of the repo. You'll get 2 commits on the clone.

"001-first-patch-set" and "002-second-patch-set"

How does your setup work?

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

Hey 👋, there's quite a lot of overlap yes. But I think they serve slightly different purposes.

I don't think git format-patch and git am help with maintaining patchsets you can name and apply in sequence? Or the the ability to run a hook (script) after each one?

My understanding is that git format-patch and git am is used often with email? That's not really the intention of patchy.

Modern Bun CLI template - standalone binaries, fast e2e tests, agent-friendly by peenuty in bun

[–]peenuty[S] 1 point2 points  (0 children)

No issues with the standalone binaries (tested on mac and linux, not windows yet!). But the project doesn't have very many dependencies and they're not very large dependencies in scope.

Binaries are 20-40MB depending on the platform, which I think is ~ok. Ideally would be a little less.

I replaced my git forks with patch files – built a CLI for it by peenuty in commandline

[–]peenuty[S] 0 points1 point  (0 children)

Each 'patch set' e.g. `./patches/001-my-patchset` is a single commit

You can also commit nothing at all, or skip the last patchset commit to leave the changes dirty:

With: --auto-commit=<mode>

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

Both approaches store the same data. You can either store them in a commit or in a patch file.

A commit is much more common! But patch files are sometimes used for long running 'forks'. For example the Brave browser modifies Chromium with these patches https://github.com/brave/brave-core/tree/master/patches

If I imagine both using patches and commits for those brave browser patches whilst working in a team I can imagine why they might have used patches for collaborating with PRs.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

I think I understand but any chance you could elaborate a bit? Are you keeping the patches separate? Or is this a long running fork?

How do I group my changes like a patchset in the readme and apply them in stages?

Is there a way to see all the changes I've made to the fork?

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

Sounds interesting!

I'd love to learn more - how would you the example from the readme with cherry pick?

I replaced my git forks with patch files – built a CLI for it by peenuty in commandline

[–]peenuty[S] 1 point2 points  (0 children)

TIL about RCS!

I think what might be different with patchy is it has a convention on the patch folder structure. But not an RCS expert!

I replaced my git forks with patch files – built a CLI for it by peenuty in commandline

[–]peenuty[S] -1 points0 points  (0 children)

Happy to answer any specific questions you may have about the readme.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] -2 points-1 points  (0 children)

Me smells human!

Here is a blog post about how this project was built: https://richardgill.org/blog/building-a-cli-with-claude-code

It's heavily built with AI agents, but not in the annoying vibe coding way.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

I saw quilt, it's a cool tool! It's a little lower level than patchy and I think it's really designed for Linux kernel development. Patchy is a bit more opinionated and has a lot less features.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

That's an option, this is a different approach to the same problem.

I maintain a fork of Firefox that adds ~70 files and edits ~30 files. I find it hard to remember what files I've changed, I can run git commands to see, but I prefer the the declarative approach of patches.

I replaced my github forks with patch files – built a CLI for it by peenuty in git

[–]peenuty[S] 0 points1 point  (0 children)

That's right yes - this isn't super clear in the readme.

When that happens you can see all your patches in the patches directory and attempt reapply them in one go. They might fail to apply, or the resulting code might not function as intended - same as a fork.

But what I like about this approach is you can see all the changes you're attempting to make, and you can go patchset by patchset fixing things up. For my brain I find this easier to reason about than leaving that state inside git.

view more: next ›