Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Difftastic: Syntax-aware structured diff tool

github.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Difftastic: Syntax-aware structured diff tool

#41

Post by pedrovhb »

zomglings wrote: post #26
pedrovhb wrote: post #24

This is cool. I work with a large Python codebase that's been around for a while (hasn't been that long since it's been completely off Python 2). It's not a bad codebase, but naturally it has almost no typing annotations, and other devs are just starting to come around to the idea. I love `mypy --strict` but it produces way too much noise with all the other code, so I've been using a tool I made that runs mypy over t…

This sounds well in line with what I have been building - a tool to take syntax-aware diffs across git commits: https://github.com/bugout-dev/locust It currently supports Python, Javascript, and Java. I like the idea of mypy changes, as well.

I'll have a look, thanks!

Re: Difftastic: Syntax-aware structured diff tool

#42

Post by NateEag »

pedrovhb wrote: post #24

This is cool. I work with a large Python codebase that's been around for a while (hasn't been that long since it's been completely off Python 2). It's not a bad codebase, but naturally it has almost no typing annotations, and other devs are just starting to come around to the idea. I love `mypy --strict` but it produces way too much noise with all the other code, so I've been using a tool I made that runs mypy over t…

I'd forgotten about this, but years ago I was working in a huge PHP nightmare codebase.

So, I hacked together a pre-commit hook that blocked the commit only if the configured style checker registered errors on lines being added by the diff.

It never got very polished, but I wound up using it in two codebases over the years.

https://github.com/NateEag/diff-check

Re: Difftastic: Syntax-aware structured diff tool

#43

Post by awinter-py »

syntax-aware semantic history would be incredibly useful for code review and codebase archaeology. better detection of global rename, refactorings, and moves would make CR diffs way less messy.

code review is a necessary but painful part of releasing good code on a team; anything that makes it slightly easier is a force multiplier for companies whose main bottleneck is software

Re: Difftastic: Syntax-aware structured diff tool

#45

Post by Wilfred »

davidkunz wrote: post #3

To ease the pain in conventional differs, we use a pre-commit hook to format the source code (prettier). This way we only see differences if something _actually_ changed.

A syntactic differ like Difftastic is very helpful when your codebase is autoformatted. Formatters often reflow code.

Given the code:

  foo(one, two, three);
If you add an argument and reformat:

  foo(
    one,
    two,
    new,
    three
  );
A line-based diff can make it hard to spot what's changed.

Re: Difftastic: Syntax-aware structured diff tool

#46

Post by Wilfred »

dan-robertson wrote: post #33

I personally am much more excited by “sliders” than the structure-aware diffs. Marking additions between [], it is the difference between e.g. handle_case [some new case over multiple lines handle_case] some existing case [ check_invariant(); } function newFunc(){ ... ] check_invariant(); } And [handle_case some new case] handle_case old case [function newFunc(){ ... check_invariant(); }]

I agree sliders are a problem, and I hope to have a solution there.

Syntactic differs already do better because they understand that parentheses/brackets are paired. Difftastic does OK with this example: https://imgur.com/a/pVlVBo5

Re: Difftastic: Syntax-aware structured diff tool

#47

Post by Wilfred »

austincheney wrote: post #6

I worked on this problem for just over a decade before moving onto other things. It’s a tough problem to solve. The biggest problem I ran into is that the largest segment of user growth were too fickle. They wanted all kinds of magic in new optional features for their personal preferences that took incredible effort. I lacked the analytics to see who used which exotic features. Most of these people just wanted a beau…

Thanks, this is good advice. There are some super featureful diff tools out there. For example, https://github.com/dandavison/delta does a line-based diff but it also syntax highlights its output.

I'm hoping that defining syntax in a separate TOML file will let end users extend difftastic for their own languages/config files. I want to keep difftastic small and manageable.

Re: Difftastic: Syntax-aware structured diff tool

#48

Post by Wilfred »

mikepurvis wrote: post #40

I'd feel so much more motivation for checking out alternative diff tools if there was a better story for integrating them with the review tools in Github, GitLab, etc. I know there's nothing anyone can do about that— it's something the Git hosts themselves have to enable, or I have to see enough benefit in it to go to an dedicated review tool to make the bother of that worthwhile. I believe Gerrit has a pluggable dif…

Definitely!

I still look at diffs in the terminal pretty often, but all my code reviews are in rendered HTML.

That said, there needs to be a credible tool before review tools can adopt it! GitHub does a line-based diff with word-based highlighting, which is probably the best you can do without syntactic smarts.

Re: Difftastic: Syntax-aware structured diff tool

#49

Post by runeks »

It's a great idea, but I don't think defining the syntax of a programming language as a syntax.toml file will work for enough programming languages for this to be useful. You're basically rewriting the parser of your language in a DSL that isn't as expressive as the language the parser is written in.

I think you'd need another parser/syntax interface for this to work. E.g. running a binary that you can submit source code to which responds with a JSON file containing the parsed tokens. That way you can reuse the compiler's parser.

Re: Difftastic: Syntax-aware structured diff tool

#50

Post by Wilfred »

dcminter wrote: post #8
secondcoming wrote: post #7

How can he have crashes if it's written in Rust?

Probably meaning 'panic' - e.g. unwrapping a Result without allowing for an error result.

Yep! There's a lot of .unwrap() and .expect() in the codebase, so it panics. Since it's Rust, you get a line number and an error message rather than a segfault.

I will tidy it up at some point, but I spend too much time throwing away ideas that don't work. Defensive code is silly if you delete it after!

Post reply on HN