Live data from Hacker News

Difftastic: A diff that understands syntax

github.com

151–160 of 224 posts

Re: Difftastic: A diff that understands syntax

#151
post #31
post #20

Earlier quoted context omitted.

> If you have consistent code style and formatting this tool is unnecessary I disagree. I struggle to replicate it right now using a simple test, but I've seen the following rather infuriating and counter intuitive behaviour from Git/GNU diff. If you have a simple if statement such as: if (bla) { // do something } And you were to add another statement at the end, after the closing curly brace, e.g.: if (bla) { // do…

There is an option [0] to use non-default but still built-in git diff algorithms that might yield better results. [0] https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

I've used a few of the different git diff algorithms and still have had problems like these.

Re: Difftastic: A diff that understands syntax

#152

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

Should've named that repo "phdiff".

Best pun I've heard in a long time. Well done. <3

Re: Difftastic: A diff that understands syntax

#154

I use meld and it seems syntax aware plus it can do merge with a click, how will difftastic diff in that regard?

I use meld too. But afaics, meld 'syntax aware' is very different from from difftastic.

Meld takes a diff, and applies syntax highlighting over the diffed files. It additionally highlights the changed characters in a line. Git diff, vimdiff and probably others, do this as well.

From the demo, I understand that Difftastic first applies syntax and then rebuilds the patch over that. Being aware of line wrapping, changes in nesting, moving codeblocks into functions and so on.

Re: Difftastic: A diff that understands syntax

#155

Earlier quoted context omitted.

I'm not too familiar with YAML, so can't answer to that. But re JSON: > object keys in a different order They can't be "in a different order" as JSON keys are not ordered. They can be whatever order, and would still be considered the same. > array items are out of order Then it's different, as JSON arrays are ordered. ["a", "b"] is not the same as ["b", "a"] while {a: 1, b: 1} and {b: 1, a: 1} is the same. > you coul…

> They can't be "in a different order" as JSON keys are not ordered. They can be whatever order, and would still be considered the same. This is what GP is saying, I'm pretty sure. Object member order is non-semantic in json, so in order to do a semantic diff (one that understands structure), you need to canonicalize the order of the two sides. Simply diffing the output of jq doesn't do that, because (afaik) jq doesn…

Just an FYI, jq has a flag to sort by the name of keys, I believe it's -k.

Re: Difftastic: A diff that understands syntax

#156
post #77

It might be useful for reviewing merge/pull requests. But is there a way to display the diff "interleaved" instead of 2-columns side-by-side? (when executing `GIT_EXTERNAL_DIFF=difft git log -p --ext-diff` for example)

We are working on a code review tool which supports unified diffs with semantic diffing. If that sounds interesting for you, take a look at https://mergeboard.com

Re: Difftastic: A diff that understands syntax

#157
post #80
post #67

Earlier quoted context omitted.

I just followed the installation instructions here: https://doc.rust-lang.org/cargo/getting-started/installation... It'll confirm that you want to install it, because it's already installed I think, and I just selected 1. for Yes.

> curl https://sh.rustup.rs -sSf | sh hard pass :)

Out of curiosity, what would be an acceptable way for the developers to provide a quick way for users to get up and running?

A get started guide with all the required commands easily copy-pastable? (A popular option these days) Something else?

I don’t mean to be critical, I’m simply curious.

Re: Difftastic: A diff that understands syntax

#159

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD ( https://github.com/VictorCMiraldo/hdiff ) and can confirm: not simple! :)

So I looked at the paper and it seems interesting. Basic idea: Instead of the operations to consider being "insert", "delete" and "copy", one adds "reorder" "contract subtree" and "duplicate" (although I didn't quite get the subtlety of copy vs duplicate on a short skim); and even though extra ops increase the search space, they actually let you search more effectively. I can buy that argument.

The practical problem, though, is that the Haskell compiler is limited/buggy, so you couldn't implement this for C, and you settled on a small language like Lua. If you _do_ extend this to other languages (perhaps port your implementation from Haskell to something else?), please post it on HN and elsewhere!

Post reply on HN