Hi Chris, hi all,
Chris Sherlock <chris.sherlock79@xxxxxxxxx> ezt írta (időpont: 2025. febr. 13., Cs, 11:37):
Hi all,
I see commits all the time where someone changes a line of code and changes the whitespacing in that same line of code.
So for example, in https://gerrit.libreoffice.org/c/core/+/178504 I have removed the using namespaces and added css:: as the prefix, but at the same time *only* on the lines of code that I touched I fixed up the inconsistent whitespacing.
I see this all the time in commits.
Given the code compiles and it is very obviously what change is being made, what is the problem with doing this?
I know you all took away my commit bit because of my whitespace changes close to a decade ago, but given I see this sort of thing being done by others all the time, I’m trying to understand where I’m being inconsistent with current practice.
When I reviewed hundreds of patch sets of the NISZ developers, partially beginners, I shared always with them, that it's the best to minimize the line changes only for the real code improvements, *because of the limited human resources for the reviewing process* (made by still volunteers mostly), so this is not only the polite way, but the optimal, too. But in my practice, there were always exceptions: keeping the motivation of our developers was even more desirable in the long term.
This is the biggest asset of our foundation: knowledge and motivation of our contributors!
At NISZ review, after fixing all the other problems made by the author (including bunch re-formatting by some exotic Windows code editor), I have fixed the remaining and annoying space differences by myself (or I left it as it is), if I felt the motivation of the developers was in danger (e.g. after dozens of patch sets made by them for a single commit, especially he/she was not a beginner any more, working on a really hard problem).
The devil is in the details. Michael is right that there are lines where only spaces have been changed, but his first comment didn't show exactly the lines he was suggesting for correction, maybe that is why he was unwittingly opening old wounds. Chris' e-mail shows for me that the motivation of the experienced and valuable contributor is at risk. Or more contributors, including Michael now.
The right solution will be one where we don't get any more wounds, but who knows what it is. That is why I have corrected the 5-6 lines, where there were only space differences, hoping the best!
Thanks for your commit and reviews!
Best regards,
László
Chris