From: Johannes Sixt <j6t@kdbg•org>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail•com>
Cc: Johannes Schindelin <johannes.schindelin@gmx•de>, git@vger•kernel.org
Subject: Re: [PATCH 1/2] mingw: avoid relative `#include`s
Date: Sun, 12 Oct 2025 13:45:50 +0200 [thread overview]
Message-ID: <e593886e-eeb4-440f-a317-a2959577e1e3@kdbg.org> (raw)
In-Reply-To: <484ef8b825e5d1d68a61f0f8cc2520457e8f4f3a.1759995961.git.gitgitgadget@gmail.com>
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
next prev parent reply other threads:[~2025-10-12 11:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 7:45 [PATCH 0/2] Organize mingw includes Johannes Schindelin via GitGitGadget
2025-10-09 7:46 ` [PATCH 1/2] mingw: avoid relative `#include`s Johannes Schindelin via GitGitGadget
2025-10-11 9:03 ` Matthias Aßhauer
2025-10-12 11:45 ` Johannes Sixt [this message]
2025-10-13 16:29 ` Junio C Hamano
2025-10-09 7:46 ` [PATCH 2/2] mingw: order `#include`s alphabetically Johannes Schindelin via GitGitGadget
2025-10-10 9:53 ` [PATCH 0/2] Organize mingw includes Patrick Steinhardt
2025-10-10 13:55 ` Johannes Schindelin
2025-10-10 16:18 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e593886e-eeb4-440f-a317-a2959577e1e3@kdbg.org \
--to=j6t@kdbg$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=johannes.schindelin@gmx$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox