Jeff King <> writes:

> I think there are basically three classes of solution:
>   1. Declare __NO_INLINE__ everywhere. I'd worry this might affect other
>      environments, who would then not inline and lose performance (but
>      since it's a non-standard macro, we don't really know what it will
>      do in other places; possibly nothing).
>   2. Declare __NO_INLINE__ on mingw. Similar to above, but we know it
>      only affects mingw, and we know the meaning of NO_INLINE there.
>   3. Try to impact only the uses as a function pointer (e.g., by using
>      a wrapper function as suggested in the thread).
> Your patch does (1), I believe. Junio's patch does (3), but is a
> maintenance burden in that any new callsites will need to remember to do
> the same trick.
> But your argument (and reading the mingw header, I agree) is that there
> is no performance difference at all between (2) and (3). And (2) does
> not have the maintenance burden. So it does seem like the right path to
> me.

Agreed.  If that #define __NO_INLINE__ does not appear in the common
part of our header files like git-compat-util.h but is limited to
somewhere in compat/, that would be the perfect outcome.

Thanks, both.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to