git/config.mak.dev, branch jch

builds: move build scripts into "tools/"

2026-03-19T13:40:09Z

We have a bunch of scripts used by our different build systems that are all located in the top-level directory. Now that we have introduced the new "tools/" directory though we have a better home for them. Move the scripts into the "tools/" directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'js/comma-semicolon-confusion'

2025-04-15T20:50:17Z

Code clean-up. * js/comma-semicolon-confusion: detect-compiler: detect clang even if it found CUDA clang: warn when the comma operator is used compat/regex: explicitly mark intentional use of the comma operator wildmatch: avoid using of the comma operator diff-delta: avoid using the comma operator xdiff: avoid using the comma operator unnecessarily clar: avoid using the comma operator unnecessarily kwset: avoid using the comma operator unnecessarily rebase: avoid using the comma operator unnecessarily remote-curl: avoid using the comma operator unnecessarily

clang: warn when the comma operator is used

2025-03-29T00:38:12Z

When compiling Git using `clang`, the `-Wcomma` option can be used to warn about code using the comma operator (because it is typically unintentional and wants to use the semicolon instead). Helped-by: Patrick Steinhardt Signed-off-by: Johannes Schindelin Acked-by: Phillip Wood Signed-off-by: Junio C Hamano

config.mak.dev: enable -Wunreachable-code

2025-03-18T00:31:28Z

Having the compiler point out unreachable code can help avoid bugs, like the one discussed in: https://lore.kernel.org/git/20250307195057.GA3675279@coredump.intra.peff.net/ In that case it was found by Coverity, but finding it earlier saves everybody time and effort. We can use -Wunreachable-code to get some help from the compiler here. Interestingly, this is a noop in gcc. It was a real warning up until gcc 4.x, when it was removed for being too flaky, but they left the command-line option to avoid breaking users. See: https://stackoverflow.com/questions/17249934/why-does-gcc-not-warn-for-unreachable-code However, clang does implement this option, and it finds the case mentioned above (and no other cases within the code base). And since we run clang in several of our CI jobs, that's enough to get an early warning of breakage. We could enable it only for clang, but since gcc is happy to ignore it, it's simpler to just turn it on for all developer builds. Signed-off-by: Jeff King [jc: squashed meson.build change sent by Patrick] Signed-off-by: Junio C Hamano

config.mak.dev: drop `-Wno-sign-compare`

2024-12-06T11:20:02Z

There is no need anymore to disable `-Wsign-compare` now that all files that cause warnings have been marked accordingly. Drop the option. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'ak/typofix-2.46-maint'

2024-09-25T17:37:12Z

Typofix. * ak/typofix-2.46-maint: upload-pack: fix a typo sideband: fix a typo setup: fix a typo run-command: fix a typo revision: fix a typo refs: fix typos rebase: fix a typo read-cache-ll: fix a typo pretty: fix a typo object-file: fix a typo merge-ort: fix typos merge-ll: fix a typo http: fix a typo gpg-interface: fix a typo git-p4: fix typos git-instaweb: fix a typo fsmonitor-settings: fix a typo diffcore-rename: fix typos config.mak.dev: fix a typo

config.mak.dev: fix a typo

2024-09-19T20:45:59Z

Fix a typo in comments. Signed-off-by: Andrew Kreimer Signed-off-by: Junio C Hamano

config.mak.dev: enable -Wunused-parameter by default

2024-08-28T16:51:18Z

Having now removed or annotated all of the unused function parameters in our code base, I found that each instance falls into one of three categories: 1. ignoring the parameter is a bug (e.g., a function takes a ptr/len pair, but ignores the length). Detecting these helps us find the bugs. 2. the parameter is unnecessary (and usually left over from a refactoring or earlier iteration of a patches series). Removing these cleans up the code. 3. the function has to conform to a specific interface (because it's used via a function pointer, or matches something on the other side of an #ifdef). These ones are annoying, but annotating them with UNUSED is not too bad (especially if the compiler tells you about the problem promptly). Certainly instances of (3) are more common than (1), but after finding all of these, I think there were enough cases of (1) that it justifies the work in annotating all of the (3)s. And since the code base is now at a spot where we compile cleanly with -Wunused-parameter, turning it on will make it the responsibility of individual patch writers going forward. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'tb/dev-build-pedantic-fix'

2024-07-15T17:11:42Z

Developer build procedure fix. * tb/dev-build-pedantic-fix: config.mak.dev: fix typo when enabling -Wpedantic

config.mak.dev: fix typo when enabling -Wpedantic

2024-07-06T22:10:29Z

In ebd2e4a13a (Makefile: restrict -Wpedantic and -Wno-pedantic-ms-format better, 2021-09-28), we tightened our Makefile's behavior to only enable -Wpedantic when compiling with either gcc5/clang4 or greater as older compiler versions did not have support for -Wpedantic. Commit ebd2e4a13a was looking for either "gcc5" or "clang4" to appear in the COMPILER_FEATURES variable, combining the two "$(filter ...)" searches with an "$(or ...)". But ebd2e4a13a has a typo where instead of writing: ifneq ($(or ($filter ...),$(filter ...)),) we wrote: ifneq (($or ($filter ...),$(filter ...)),) Causing our Makefile (when invoked with DEVELOPER=1, and a sufficiently recent compiler version) to barf: $ make DEVELOPER=1 config.mak.dev:13: extraneous text after 'ifneq' directive [...] Correctly combine the results of the two "$(filter ...)" operations by using "$(or ...)", not "$or". Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano