Re: [Ksummit-discuss] Should we force include <linux/err.h> when compiling all .c files?

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Jul 28, 2014 at 03:53:02PM -0700, H. Peter Anvin wrote:
> On 07/28/2014 01:16 PM, Julia Lawall wrote:
> >>
> >> We have such a clear procedure.  It involves pre-arranging with Linus
> >> *before the merge window begins* to run the script in question
> >> *immediately before releasing rc1*.
> > 
> > In this case, would it really create many conflicts?  Does the list of 
> > included files change often.

Across thousands of source files?  Often enough to have significant
conflicts during a merge window.  More importantly, new source files
using error pointers get added often enough that a submitted patch would
likely be incomplete (which would not show up as a merge conflict).

> > If there is an optimial position for the include, it could be hard to make 
> > a perfect script.
> > 
> 
> In this case it probably doesn't matter much, because there is a key
> difference between this and most other patchsets of this type: there is
> an order that this can be done which is safe.  Specifically, add the
> #include where it needs to go as a patch series, and then remove it from
> the build.  If this is merged into a git tree and the resulting build
> fails, it will be obvious what needs to happen, and sfr and Linus are
> really good about managing that in linux-next and mainline,
> respectively, so I don't even think we need to go to this "special
> procedure" for this case.

Perhaps, though see above about the handling of new source files.

But this also seems like a good example of when fine-grained commits can
go wrong.  Given mechanical changes to several thousand source files,
does it really make sense to break those changes up into hundreds of
commits, all of which will share the same commit message except for the
prefix at the start of the subject?  Or would it make more sense to just
commit it and submit it as a single change?

(By contrast with, for instance, warning fixes, for which the changes
warrant subsystem-specific review.)

- Josh Triplett