[Alupis]

the link you provided has no "just formatting only" changes. The non-functional changes you see there are updating documentation in comments. That is a big difference. You won't ever see "i just felt like we should have an extra blank line here" changes.

[3JPLW]

Hunh? Try the staging: unisys: fix formatting in timskmod.h patch - e5700df52 [1]

    diff --git a/drivers/staging/unisys/include/timskmod.h b/drivers/staging/unisys/include/timskmod.h
    index b20fc9d..59144ba 100644
    --- a/drivers/staging/unisys/include/timskmod.h
    +++ b/drivers/staging/unisys/include/timskmod.h
    @@ -293,6 +293,7 @@ static inline struct cdev *cdev_alloc_init(struct module *owner,
     					   const struct file_operations *fops)
     {
     	struct cdev *cdev = NULL;
    +
     	cdev = cdev_alloc();
     	if (!cdev)
     		return NULL;

(This commit just happened to be the only one I peeked at from the link above - and is particularly apropos)

1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

[Alupis]

well i stand corrected it seems. although if that is from staging, then it will likely get squashed before merged into mainline (meaning this commit won't actually stay in the history).

[cesarb]

Staging is an exception. Staging is a place to put low-quality drivers developed outside the Linux kernel community, to be fixed to Linux kernel standards before being moved into the normal tree. One of the many things done to a driver in staging is to fix the source code formatting. The commits won't get squashed, since it's part of the mainline git repository, which is never squashed.

So yeah, on staging you can expect to see lots of non-functional changes, mixed with functional changes.