Organize mingw includes

Following in the footsteps of the many, many recent #include refactorings, this patch series orders the #include statements in compat/mingw.c.

Johannes Schindelin (2):
mingw: avoid relative #includes
mingw: order #includes alphabetically

 compat/mingw.c | 30 +++++++++++++++---------------
 1 file changed, 15 insertions(+), 15 deletions(-)

base-commit: 79cf913ea9321f774da29b2330b5781d5ff420ef
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1985%2Fdscho%2Forganize-mingw-includes-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1985/dscho/organize-mingw-includes-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1985

gitgitgadget

From: Johannes Schindelin <[email protected]>

We want to make them relative to the top-level directory.

---
 compat/mingw.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

index 8538e3d172..da99473f56 100644
@@ -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

gitgitgadget

From: Johannes Schindelin <[email protected]>

It allows for more consistent patches that way.

---
 compat/mingw.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

index da99473f56..736a07a028 100644
@@ -2,25 +2,25 @@
 #define DISABLE_SIGN_COMPARE_WARNINGS
 
 #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 "win32/lazyload.h"
 #include "config.h"
+#include "dir.h"
 #include "environment.h"
-#include "trace2.h"
+#include "gettext.h"
+#include "run-command.h"
+#include "strbuf.h"
 #include "symlinks.h"
+#include "trace2.h"
+#include "win32.h"
+#include "win32/lazyload.h"
 #include "wrapper.h"
-#include "dir.h"
-#include "gettext.h"
+#include <aclapi.h>
+#include <conio.h>
+#include <sddl.h>
 #define SECURITY_WIN32
 #include <sspi.h>
+#include <wchar.h>
 #include <winternl.h>
 
 #define STATUS_DELETE_PENDING ((NTSTATUS) 0xC0000056)

gitgitgadget

Both of these patches look good to me and I like the improved consistency that they bring. I may also do the same for our code in "refs/", where some of the files use relative includes, as well. Might be worth to document this somewhere if it isn't already, but that doesn't have to be part of your patch series here.

Sorting them also makes sense. It's another thing where I wish that we had a tool to enforce this. clang-format supports this in theory, but it's disabled right now. And I'm not even sure whether it can be told to include e.g. "git-compat-util.h" first.

Thanks!

Patrick

Hi Patrick,

There's already such a lot of documentation that I fear it is intimidating to any new contributor (and if I was one, I'd be tempted to read it exclusively via AI summaries). I don't want to add to that amount.

In theory, I am totally with you: Sorting #includes is a job best left to tools. But then, I say the same about formatting, and I see a lot of appetite on this list for preventing that to become a tool-driven job, and instead requiring developer time to be spent on it. Therefore, I don't want to spend any effort trying to get this automated when I see small chances of success in the endeavor of freeing up cognitive cycles for tasks I find more intellectually rewarding than figuring out where a space or a line break goes.

Ciao,
Johannes

I am afraid that it is apples-to-oranges comparison. Nobody has to read the #include directives; they may have to see if a header they care about (because they are planning to add a call to a function that hasn't been used in the particular C source file, perhaps) is already included, and sorted list of includes is a good tool to help them. IOW, they do not read them, they scan in them. But the code, the result of formatting, must be readable by people.

Am 09.10.25 um 09:46 schrieb Johannes Schindelin via GitGitGadget:

;-)

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

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

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.