4 ms·
10 years ago would probably long enough ago to not care for me. But wouldn’t the standard -w be enough to ignore most of this commit. But I used ignoreRevs in
by bhaak 5y ago
10 years ago would probably long enough ago to not care for me.
But wouldn’t the standard -w be enough to ignore most of this commit.
But I used ignoreRevs in repositories that messed up their history by using an automatic indenter with atrocious settings.
- gumby 5y agoUnfortunately -w won't help you with patch, which uses character positions. But certainly helps with searching.
- harikb 5y agoIn addition, if their code is python, -w would incorrectly ignore legitimate changes
- jrochkind1 5y agodo you have a realistic example?
- contravariant 5y agoA simple one would be: total = 0 for value in list: total += value return total vs. total = 0 for value in list: total += value return total
- jrochkind1 5y agoah, fixing a bug, ok. I was trying to think of two hypothetical correctly functioning programs identical but for whitespace, and thinking that was probably pretty rare.
- contravariant 5y agoWell the first one simply returns the first value of the list, which can be correct. I just gave the variables names that turned this into a bugfix.
- jrochkind1 5y agoI don't see any sane reason you'd intentionally access the first element only of a list by using a for loop with a non-conditional return. But anyway okeydoke. I do wonder if there are any realistic non-bugfix refactors/enhancements that would result in a whitespace-only change, or in general how often in a real codebase you are going to get a whitespace-only commit diff. But yeah, I understand it is possible, cool.
- tazjin 5y ago> 10 years ago would probably long enough ago to not care for me. Hm, especially for the case of blaming (mostly to figure out why something was done a certain way) I frequently happen upon 10+ year old commits. This happens both in open-source projects, as well as at work (where we don't use git, but the same concepts apply).