On Thu, 9 Oct 2025, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> We want to make them relative to the top-level directory.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> compat/mingw.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 8538e3d172..da99473f56 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1,22 +1,22 @@
> #define USE_THE_REPOSITORY_VARIABLE
> #define DISABLE_SIGN_COMPARE_WARNINGS
>
> -#include "../git-compat-util.h"
> +#include "git-compat-util.h"
> #include "win32.h"

Isn't this include also relative to compat/ and should become #include "compat/win32.h"?

> #include <aclapi.h>
> #include <sddl.h>
> #include <conio.h>
> #include <wchar.h>
> -#include "../strbuf.h"
> -#include "../run-command.h"
> -#include "../abspath.h"
> -#include "../alloc.h"
> +#include "strbuf.h"
> +#include "run-command.h"
> +#include "abspath.h"
> +#include "alloc.h"
> #include "win32/lazyload.h"

Same situation here.

best regards

Matthias

Am 09.10.25 um 09:46 schrieb Johannes Schindelin via GitGitGadget:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> We want to make them relative to the top-level directory.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  compat/mingw.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 8538e3d172..da99473f56 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -1,22 +1,22 @@
>  #define USE_THE_REPOSITORY_VARIABLE
>  #define DISABLE_SIGN_COMPARE_WARNINGS
>  
> -#include "../git-compat-util.h"
> +#include "git-compat-util.h"
>  #include "win32.h"
>  #include <aclapi.h>
>  #include <sddl.h>
>  #include <conio.h>
>  #include <wchar.h>
> -#include "../strbuf.h"
> -#include "../run-command.h"
> -#include "../abspath.h"
> -#include "../alloc.h"
> +#include "strbuf.h"
> +#include "run-command.h"
> +#include "abspath.h"
> +#include "alloc.h"
>  #include "win32/lazyload.h"
> -#include "../config.h"
> -#include "../environment.h"
> -#include "../trace2.h"
> -#include "../symlinks.h"
> -#include "../wrapper.h"
> +#include "config.h"
> +#include "environment.h"
> +#include "trace2.h"
> +#include "symlinks.h"
> +#include "wrapper.h"
>  #include "dir.h"
>  #include "gettext.h"
>  #define SECURITY_WIN32

Why is this needed?

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. But that I wouldn't regard as desirable, either, because the
included file isn't from a subordinate module or library.

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

-- Hannes

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.