Patch Set 1: -Code-Review
I've done too much blame-chasing in my time as flashrom maintainer and would rather not repeat that ever again. When you're trying to track down a bug, the age of the code is less relevant than the number of no-op commits you have to wade through.
With regard to reformatting, both a reformat with tabs and a reformat with spaces do not make much sense. Once a new programmer with a longer name than expected comes along, someone will reformat the whole file again. And again. Not having this aligned is actually a feature, because then you don't have to realign it.
Carl-Daniel raises a good point about relying on spaces/tabs being fragile... I guess we could impose a length limit for programmer name, or put each element on its own line? Or just leave it alone.
That's fair. I think ultimately we just lack a standard on these things and a pre-submit hook to check said lint issues. Maybe we should only refactor with a hook coupled into the same commit to avoid regressions in stylistic changes and to keep things consistent for whatever we agree on.
Thanks Angel for putting in the work into flashrom and the suggestion regardless!
I'm not sold on the blame argument since that can be used to argue against just about any non-critical refactoring or cleanup task. However I sympathize with wanting to make blame-chasing simpler.
I agree, that is a problem with the tool not the code. Although you can avoid this with `git blame ~<refactor_hash> path/file`, a little unfortunate however shouldn't block a refactor where it makes sense.
Patch set 1:Code-Review +1
To view, visit change 38662. To unsubscribe, or for help writing mail filters, visit settings.