111–120 of 224 posts
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 :)
Why? You're willing to run some random open source project, but you're not willing to run the official Rust installation script?
If you have consistent code style and formatting this tool is unnecessary. I think that solution is better, you get a more consistent code base that is easier to read for humans. (Also diffs will be faster to compute)
> 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…
Earlier quoted context omitted.
Even if you are consistent, having unchanged indented text show up differently is very clever. I often end up reviewing a diff that moves a basic block into a conditional branch and have to scan each line to see if it changed.
If you're using a language that doesn't depend on indentation (C, Java, Go, Rust etc), try "diff -b" or "git diff -b". The indented basic block won't show as a difference, only the start and end of the block.
Earlier quoted context omitted.
Indeed. One could just do `diff $(jq . $fileOne) $(jq . $fileTwo)` and you'll end up with a "nice enough" diff even if $fileOne and $fileTwo were very differently formatted.
The problem is when a file also needs to be normalized - e.g. object keys in a different order, YAML syntax expansion. It can be very useful to indicate when a JSON file is identical to another JSON file but some of the properties or array items are out of order and that requires more in-depth knowledge of the data format. Let's not mention that you could UTF-8 encode characters or write out the same character using…
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 could UTF-8 encode characters or write out the same character using backslash notation, numeric or boolean data that might be wrapped in a string in one file but not in another
Then again, they are different. If the data inside is different, it's different.
I understand that logically, they are the same, but not syntax-wise, which is why I included the "differently formatted" "disclaimer", it wouldn't obviously understand that "one" and "1" is the same, but then again, should you? Depends on use case I'd say, hard to generalize.
This looks absolutely amazing. One thing I do find interesting (and a wish were different) is that only programming languages are supported, rather than data formats as well. For example, two JSON documents may be valid but formatted slightly differently, or a common task for me is comparing two YAML files. Comparing config files that have a well defined syntax and or can be abstracted into a tree (JSON, YAML, TOML,…
I would naively expect that this problem is easiest to solve for languages like JSON that have an unambiguous way to be pretty printed.
Earlier quoted context omitted.
I don't understand that question. Given the following source file that does not parse var foo = bar baz there are many ways to change it and make it parse including the following reasonable ones var foo = barbaz var foo = "bar baz" var foo = { bar, baz } var foo = bar // baz var foo = bar //var foo = bar baz var foo = bar * baz var foo = bar + baz var foo = bar.baz var foo = bar(baz) but also unreasonable ones like v…
My point was that test suites should give you a heuristic on what corrections are good and which are bad. A source code change that turns a test fail into a test pass should be considered an improvement.
A related thing is cregit, which does diffs of tokens: https://github.com/cregit/cregit https://lwn.net/Articles/698425/
Earlier quoted context omitted.
Not OP, but the docs call out some "Tricky Cases" [1]. [1] https://difftastic.wilfred.me.uk/tricky_cases.html
I’d imagine there’s some challenging judgement calls that such a tool would have to make. Like, in Go, you can reorder the members of a struct definition. In many cases this is just diff noise to reviewers. HOWEVER, it does impact the layout of the struct in memory, so it can be semantically meaningful in performance work.
e.g. see https://groups.google.com/g/golang-nuts/c/1BlZDNBLiAM
Having said that: if a Go compiler for a given architecture decided to change its layout algorithm, I'm pretty sure it would earn a changelog entry.
Earlier quoted context omitted.
>shell >universal * laughs in Windows, then cries *
I used to straddle the two worlds, maintained and supported a multi-site AD domain with AFS integration for user $HOME and some sort of unholy LDAP/kerberos bridge for login. About once every year or two I'll miss something about the way Windows does things, compared to normal (meaning "linux"). Like the NTFS permissions model, that's cool. But it's just once a year :) And the last time I was deep in windows was win7…
It's really not that bad, the AD-IPA cross-forest trust is really solid as is the native sssd-ad integration if IPA is too much. Honestly I can't really imagine it any other way now, so much work has been put into AD support that it's actually the best login experience on Linux at the moment. OpenLDAP is definitely showing its age -- dgmr I use it for all my personal infra because it's free and my use-cases are dead simple but we got to delete so much bespoke code after migrating off it at work.