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...
Difftastic: A diff that understands syntax
151–160 of 224 posts
Re: Difftastic: A diff that understands syntax
#152I 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".
Re: Difftastic: A diff that understands syntax
#153Re: Difftastic: A diff that understands syntax
#154I use meld and it seems syntax aware plus it can do merge with a click, how will difftastic diff in that regard?
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
#155Earlier 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…
Re: Difftastic: A diff that understands syntax
#156It 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)
Re: Difftastic: A diff that understands syntax
#157Earlier 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 :)
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
#158Re: Difftastic: A diff that understands syntax
#159I 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! :)
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!
Re: Difftastic: A diff that understands syntax
#160> Difftastic output is intended for human consumption
Why not separate the human-consumption part and the underlying parsing part? Or at least provide both in the same utility?