On 29/08/18 18:01, Volodymyr Babchuk wrote: > Hi Andrew, > > On 29.08.18 19:22, Andrew Cooper wrote: >> On 29/08/18 17:11, Volodymyr Babchuk wrote: >>> Hello all, >>> >>> During xen hacking I often encounter white spaces at EOLs. It is quite >>> annoying to see red marker in, say, xen/arch/arm/domctl.c:25 >>> >>> I used sed to create patch that removes all such whitespaces. Command >>> is simple: >>> >>> # find xen -name "*.[ch]" | xargs sed -i "s/[[:space:]]*$//g" >>> >>> Problem is that patch is quite big: >>> >>> 285 files changed, 1463 insertions(+), 1463 deletions(-) >>> >>> So what is the best way to publish this fix? I can just send it to ML >>> as one patch. There is no functional changes, so should I add >>> maintainers? >>> >> >> There are more files than that. By my count, its: >> >> 307 files changed, 1586 insertions(+), 1586 deletions(-) > I tried to fix only *.c and *.h files. With COPYINGs, READMEs, > makefiles, and so on I got > > 309 files changed, 1599 insertions(+), 1599 deletions(-) > > >> In the past, it has been the view that fixing this all in one go might >> be too intrusive to people developing series. Then again, since the >> last time this was discussed, we've switched from hg to git as a base >> VCS, and git rebase has no issues coping with trailing whitespace >> changes. > > Also there is --ignore-space-change and --ignore-whitespace, so > developers and maintainers will be able to rebase changes without much > effort. > >> We've been fixing it as we go, but it is very slow going. I've got half >> a mind to suggest that we just commit a single fix and call it done... > I can't find a better solution. At first I though to fix them manually > in places where I see them. But then, why should I include fixes for > some files and not include for others? How to chose which files should > be fixed and which - not? So, I think it is better to fix all in > single commit. > > Another solution that I can see is to ask maintainers to provide > patches for own subsystems.
Getting the fix into the tree is trivial, and most easily done by one of the committers, if the community can agree that its a sensible thing to do. FWIW, +1 to getting it fixed and removing the problem completely. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
