Calvin Wan [off-list ref] writes:

git-compat-util.h has grown to a large and difficult to read file partly
because its set of functionality is overloaded. Besides being a
compatibility file that ensures Git's operation across different
operating systems, it has also become a dumping ground for commonly used
macros and static inline functions.

Yeah, compat-util.h started out as a (surprise) "compatibility aid"
that isolates the knowledge of platform specific inclusion order,
what feature macros to define before including which system header
file, etc.  "A dumping ground for common stuff"---aptly put ;-).

This commit separates out macros and static inline functions that are
compatible across operating systems into common.h.

It sounds a bit too generic a name to me, but OK.

At some level I am more or less indifferent, in the sense that both
compat-util and common need to be included by a .c file anyway,
whether it is _our_ source, or in a future third-party source that
wants to link with the libified part of Git, so it does notreally
make much of a difference if ARRAY_SIZE() is defined in which one of
these two headers.  But presumably such a future third-party source
may arrange their own system support using their own counterpart to
compat-util without using ours, and if that is what motivates this
change, I could understand why a more-or-less git-agnostic common.h
could be a good idea.

Everything, other than sane-ctype macros, does look like a generally
useful git-agnostic helper functions.  If we were to move in this
direction, I probably would prefer to separate sane-ctype macros in
a separate header, simply because they are _designed_ to override
system supplied ones and some third-party source may not want to use
such a "feature".