From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 13 Oct 2025 16:29:27 GMT
Subject: Re: [PATCH 1/2] mingw: avoid relative `#include`s
Message-ID: <xmqqa51u3guw.fsf@gitster.g>
In-Reply-To: <e593886e-eeb4-440f-a317-a2959577e1e3@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

> Why is this needed?

;-)

As pointed out by Matthias, the changes in the posted patch are not
complete/comprehensive.

> With #include "foo" it is quite clear that the file is first looked up
> from the directory of the file being processed. The changed code
> requires that the top-level directory is among the -I directives of the
> command lines. Then it would be much more logical to use #include <foo>
> instead.

I actually prefer that, but that is a taste thing I do not want to
impose on this project.

> So, IMO, the status quo is perfect and does not need this change.

I tend to agree, but it would be a waste of time to further discuss
on this.  As long as it does not break compilation, I'll just let
the patch graduate.

My preference is to 

 * always name custom headers using the path from the top-level (we
   use -I in BASIC_CFLAGS exactly for this purpose), 
   e.g.

	#include "compat/win32.h" (good)
	#include "win32.h" (not good)

 * compat header that aims to replace system supplied headers like
   <regex.h> should use -I appropriately and appear as if they are
   from the system, e.g.

	#include <regex.h> (good)
	#include "compat/regex/regex.h" (not good)

If somebody truly wants to improve things once the dust settles from
these patches, I would appreciate they keep the above in mind.

THanks.