Difftastic: Syntax-aware structured diff tool

Post by dan-robertson » Thu, Jul 08, 2021, 12:04 PM UTC

vcmiraldo wrote: post #29

That is a really difficult problem for more reasons than what fits in this comment :) In fact, I got my PhD studying this very problem ( https://victorcmiraldo.github.io/data/MiraldoPhD.pdf ). I did not find any description of how your diffing algorithm works nor how you represent a patch. I'd be really curious to know more.

Post by dan-robertson » Thu, Jul 08, 2021, 12:13 PM UTC

  handle_case [some new
    case over multiple lines
  handle_case] some existing case
  
  [  check_invariant();
  }
  
  function newFunc(){
    ...
  ]  check_invariant();
  }

  [handle_case some
    new case]
  handle_case old case

  [function newFunc(){
    ...
    check_invariant();
  }]

Post by vcmiraldo » Thu, Jul 08, 2021, 12:46 PM UTC

dan-robertson wrote: post #31

vcmiraldo wrote: post #29

That is a really difficult problem for more reasons than what fits in this comment :) In fact, I got my PhD studying this very problem ( https://victorcmiraldo.github.io/data/MiraldoPhD.pdf ). I did not find any description of how your diffing algorithm works nor how you represent a patch. I'd be really curious to know more.

I think the diffing is the “obvious” graph search algorithm between trees, where a “tree” is a list of atoms or trees (think lisp lists). Basically to diff a tree of n top-level elements against one of m elements, construct a graph where nodes lie on an (n+1)x(m+1) grid. Each node (a,b) corresponds to having looked at a elements of the first and matched them to b elements of the second list. Add edges (a,b)->(a+1,b)…

Post by llimllib » Thu, Jul 08, 2021, 2:00 PM UTC

Cthulhu_ wrote: post #9

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.

I think code formatting should be mandatory and one of the first things you adopt in your project. Resist code style rule changes as much as possible, and if you do, apply them across the whole codebase in one go to avoid churn and noise in diffs down the line. And if you do make style changes, put them in a separate commit at the very least so the diffs are cleaner and code reviews are easier. In my project I use go…

Post by tlamponi » Thu, Jul 08, 2021, 2:19 PM UTC

  git diff --word-diff=color --word-diff-regex='\w+'

  [alias]
    word-show = show --word-diff=color --word-diff-regex='\\w+'
    word-diff = diff --word-diff=color --word-diff-regex='\\w+'