RE: Clarifying confusion of our variable placement rules caused by cleanup.h

["Bird, Tim" <Tim.Bird@sony.com>]

> -----Original Message-----
> From: Alexey Dobriyan <adobriyan@gmail.com>
> 
> On Fri, Jan 02, 2026 at 09:50:29AM -0500, Steven Rostedt wrote:
> > On Wed, 31 Dec 2025 13:17:32 +0100
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >
> > > > There was variation of this type of nonsense with headers (not only it has
> > > > to be sorted alphabetically but by length too!)
> > >
> > > By length it indeed sounds weird, but alphabetical is the natural language
> > > order everybody learnt from the daycare / school years, so it's properly
> > > programmed in our deep brain. Having that allows to find easily if anything one
> > > is interested in is already being included. Also it allows to avoid dup inclusions
> > > (was there, fixed that for real). So, it's not bad.
> >
> > Actually, I like the "by length" because its aesthetically easier on the eyes.
> >
> > Alphabetically is fine, but either one helps in catching duplicate headers.
> 
> Such rules for headers are mostly harmless -- headers are supposed to be
> idempotent so ordering doesn't matter. But if ordering doesn't matter
> why have a rule at all?
The rule is (or at least was, at one point) helpful to reduce the likelihood
merge conflicts during patch application.  I know patch and quilt still
don't ignore mismatched #include lines in the patch context, even
though #include lines in C are independent of each other.  I'm not sure if git
handles this better or not.

When everyone appends new #include lines at the end of the block of lines,
there is more likelihood of a patch conflict right there.  If the #include lines
are instead sorted in some fashion, it reduces (but obviously does not eliminate)
the possibility of a patch conflict.
 -- Tim