Finally gave this a proper try on our carrier board repo. We've got two people pushing layout changes and the old workflow was checkout both branches, open two KiCad windows, squint back and forth until I found what moved. Genuinely awful on a file that's thousands of lines long. Set it up against our GitHub repo in about five minutes. It loaded the project right from the repo, no account needed for public ones, and everythign renders locally wich I like. I clicked a USB data net in the schematic and it lit up the same trace on the board and in the 3D view. The diff view listed every pad and trace change between the two branches with both versions side by side, which caught a footprint my coworker swapped that I would have missed. Dropped a couple review comments pinned right to a net and they showed up as normal pull request comments on github.com, so the rest of the team didn't have to install anything. Still early days for the project but it allready earned a spot in my workflow.
Spent last night reviewing our board changes in the browser instead of diffing files by hand
Nov 09, 2026
Last reply: 11 hours ago
5 Replies
I've been running KiVi on our sensor breakout repo for about two months now, and it honestly changed how I review my own commits as much as other people's. I'll open a PR, click through the diff, and catch dumb stuff I did at midnight, like that time I nudged a decoupling cap two pads over and never noticed until the tool showed it side by side. That alone paid for the setup time. One thing I'd add from experience: the graphical diff is not a substitute for checking the netlist itself. We had a case where the layout looked unchanged but a re-import had silently renumbered some hidden pins on a connector footprint. The rendered view showed nothing moved because the pads were in the same spots, so now I run the DRC comparison in parallel and treat the visual diff as half the check.
Also, on boards over roughly 200 components the diff view gets slow on my old laptop. My teammate's newer machine handles it fine, so prolly just a hardware thing, but worth knowing if you're on a five-year-old machine like mine.
The comment pinning to GitHub is the killer feature for me. Our mechanical engineer reviews PRs from his phone during his commute and leaves comments without touching anything KiCad related. Whatever friction that removes is worth a lot.
I gave it a spin last weekend on a private repo and ran into friction that made me stick with my current setup for now. The schematic side worked fine for viewing, but our board has a few custom library parts and one of them refused to render at all, which kind of killed my confidence in the diff output since I couldn't be sure the missing footprint wasn't hiding something. Filed an issue and the developer responded the same day, so credit where it's due, but I need the viewer to be trustworthy before I pin comments to it. What I've ended up doing instead is a poor man's version: I export the board to SVG on each commit with a small script in the repo, then flip through the SVGs when reviewing. Crude, no interactivity, but it catches moved traces and it never chokes on custom parts since the export happens in KiCad itself. That said, the click-a-net-and-see-it-everywhere behavior is genuinely the thing I miss most. Hunting down where a power net runs by hand gets old fast, and if the footprint rendering gets fixed I'll probably give it another shot. For anyone else with wierd library stuff, just test that part first before committing to the workflow.
Been using this on our motor driver project for the last few weeks, maybe 40 pull requests in at this point. The thing I end up using most is opening an old tag to see exactly what the board looked like when we shipped rev B last year. Production came back twice asking why a via moved, and having the answer in one click instead of digging thru old branches was nice. Anyone know if self-hosted GitLab is on the roadmap? All our repos sit on an internal server, so right now I'm mirroring to a public host just so the tool can read them, which our IT department is not thrilled about.
What sold me on actually keeping it installed was how useless plain text diffs are on .kicad_pcb files in the first place. Git would show me 900 changed lines because KiCad rewrites coordinate formatting or track order on save, and I'd just approve it blind, which in hindsight is terrifying. With the rendered diff I can finally tell a real change apart from noise, and I've started leaving a review comment on my own commits when I move something deliberately so future me has context. Curious wether anyone has tried running it against a bare mirror repo with no forge behind it at all, since half my stuff lives on a self-hosted git server.
Update: it's settled into our review routine, mostly for catching midnight edits like that guy mentioned with the cap moved a pad over. Been there. Still stuck on custom library symbols though, same as the private repo poster. One of our parts renders blank and I don't trust the diff without it. Anyone found a workaround for nonstandard footprints, or is that just a known gap right now?
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required