On Wed, Jan 31, 2018 at 12:53:38PM +0200, Nikolay Borisov wrote: > > This is an unrelated change. Please don't mix pure white > > space/indentation changes with functional changes. > > David seems rather adamant in not accepting pure whitespace/indention > changes on their own so I don't see a way to actually improve the code > base in that regard unless i slip them up when modifying nearby code. If it's an unrelated change, than it's wrong to slip it in just because it's near. It's still an unrelated change. Other than that, and I think I mentioned that in your previous attempts to add whitespace changes, it just pollutes the commit history. Looking for a commit that potentially broke some code and finding a whitespace change just makes anybody grumpy. Maintaner should know and not let such changes in. I've been on both sides, and based on this experience I will not let in such changes. The review process in the mailinglist is there to catch that and point out, though pointing out just whitespace is kind of not welcome, unless the real review is also done. If there are minor things to fix, I do that at commit time, which means I edit majority of all patches or changelogs. In some cases I will let the patch author know so I don't have to fix that over and over again. (But it never lasts.) > There are a couple of space with trailing whitespace which I constantly > select out from my commits. > > Given that you have now also expressed objection to such cleanups, how > should they eventually be fixed? They will be fixed once the code on those lines gets changed. Which may not anytime soon. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
