@[email protected] to [email protected] • 2 months agoHow far should a programming language aware diff go?semanticdiff.comexternal-linkmessage-square19fedilinkarrow-up11arrow-down10cross-posted to: programming
arrow-up11arrow-down1external-linkHow far should a programming language aware diff go?semanticdiff.com@[email protected] to [email protected] • 2 months agomessage-square19fedilinkcross-posted to: programming
minus-square@[email protected]linkfedilink0•2 months agoThe example for 2 isn’t good. Seemingly superfluous commas, brackets, and escaped newlines can be useful and even important for clean maintenance. The solution to the whitespace gripe is strictly enforced formatting standards with a git hook running a manually invokable script.
minus-square@[email protected]cakelinkfedilink0•2 months agoYeah but sometimes you do get meaningless changes that aren’t just whitespace even with auto formatters. For example if you change the indentation on some code and that causes it to wrap an expression.
minus-square@[email protected]cakelinkfedilink0•2 months agogit diff -w only ignores whitespace within a line (e.g. changing indentation). It doesn’t ignore adding or removing new lines. But even if it did, wrapping a function call or a long string can introduce extra commas or quotes.
The example for 2 isn’t good. Seemingly superfluous commas, brackets, and escaped newlines can be useful and even important for clean maintenance.
The solution to the whitespace gripe is strictly enforced formatting standards with a git hook running a manually invokable script.
Yeah but sometimes you do get meaningless changes that aren’t just whitespace even with auto formatters. For example if you change the indentation on some code and that causes it to wrap an expression.
How is that not whitespace?
git diff -wonly ignores whitespace within a line (e.g. changing indentation). It doesn’t ignore adding or removing new lines.But even if it did, wrapping a function call or a long string can introduce extra commas or quotes.