HN Reader

Very impressive enhancement. Not a panacea though. It uses tree-sitter approach to solve situations when two users change the same line of code. For example one change function name and other adds a new argument. It will merge it without conflicts. It still has some troubles to solve complex issues, without knowing author intensions. But can significantly simplify developers' lives. Not sure if it would land into git very soon. It requires all git to know all the parsers you need. But definitely worth adding.

I tried using Mergiraf a year or so ago, and ended up with so many weird problems that I eventually tracked down to being caused by it, that I disabled and uninstalled it and never looked back - it was more hassle than it was worth

- Related in fine-grained diffing approach: Git heatmap: diff viewer for code reviews

> Heatmap color-codes every diff line/token by how much human attention it probably needs. Unlike PR-review bots, we try to flag not just by “is it a bug?” but by “is it worth a second look?” (examples: hard-coded secret, weird crypto mode, gnarly logic).

https://0github.com/

fyi, comes configured in jj by default. Just `jj resolve --tool mergiraf` and some conflicts go away :)

This is a very interesting idea that could save a lot of time and pain in big projects.

The example shown reminds me pf Zed's CRDTs [1], and their journey to build a fine-grained version control system for agentic development [2]—I imagine this work could prove useful to the Zed/Cursor team, and likely shares a lot of functionality with DeltaDB [2].

- [1]: https://zed.dev/blog/crdts

- [2]: https://zed.dev/blog/sequoia-backs-zed

> After extracting a list of every merge conflict in the kernel's Git history, I tried using Mergiraf to resolve them. 6,987 still resulted in conflicts, but 428 were resolved successfully. A much larger fraction of merge conflicts were still partially resolved.

Have been using Mergiraf for the past 4 months. It's automatically solved about 70% of my conflicts and, luckily, I've never contested any of them. Pretty pleased.

I wish there were a lot more syntax aware merges built into git (et al). Why are separate columns on the same row of a CSV or multiple appends to a list (in any language you don't want a trailing comma) so annoying to merge?

It could be so much better.

Very interesting to see what Tree Sitter starting to get used for more things.

I really liked the last section of your article, thanks for the numbers

> Therefore, this merge conflict can be resolved automatically by putting the lines in any order. The resulting merged program has the same behavior either way.

That means that if I the programmer care about the order, I must now review lines, where no merge conflict is indicated. I am not sure I would like that.

finally...

I've been using 1-arg-1-line to avoid most conflicts

claude "resolve merge conflicts"

Way back in the day when I primarily wrote c# I used to use a tool called SemanticMerge. It was pretty cool, it actually parsed the code and could pick up refactors like moving a method to a different class and what not. This kinda reminds me of that a bit.

Don't use it in when you write code for critical infrastructure or aviation please. :)