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.
--
Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
