The codebase has been updated to use the newer utimensat() POSIX
function instead of the obsolescent utime(), allowing
high-precision timestamps while preserving fallback compatibility.
* as/utimensat-utimes:
compat/posix: drop legacy <utime.h> header and shims
treewide: use utimensat(2) instead of legacy utime(3p)
compat/posix: introduce utimensat(2) wrapper
When an HTTP request triggers a redirect and the target yields an
authentication challenge, the WWW-Authenticate headers received
during the redirect are now explicitly preserved across the
credential URL update, fixing an issue where they were incorrectly
cleared.
* ap/http-preserve-wwwauth-redirect:
http: preserve wwwauth_headers across redirects
The shell script implementation of 'git subtree' has been updated to
check for the presence of the configuration file of the new Rust
implementation, preventing users from accidentally running the old
script on repositories already managed by the new tool.
* ij/subtree-reject-v2-config:
git-subtree: Bail out if we find output from Rust rewrite (test)
git-subtree: Bail out if we find output from Rust rewrite
Assorted fixes for code paths that are not careful with boundary and
error conditions.
* js/coverity-fixes:
test-read-midx: check midx_fill_entry() result
oss-fuzz: handle reftable iterator initialization failures
t/unit-tests: check reftable iterator initialization
rerere: do not record failed conflict resolution data
midx: validate incremental MIDX pack IDs
gpg-interface: make signature-prefix matching length-aware
wrapper: guard writev_in_full() against signed overflow
The server-side protocol v2 response order for 'wanted-refs' and
'shallow-info' has been swapped to match the client's expectation,
fixing a fetch failure when the server has 'uploadpack.allowRefInWant'
enabled and the client performs a shallow fetch.
* rr/upload-pack-swap-shallow-wanted-ref:
upload-pack: swap wanted-ref/shallow-info responses
The can_all_from_reach() and can_all_from_reach_with_flag()
functions have been updated to accept a repository context,
preventing bugs where submodule merging incorrectly reads from the
superproject's commit-graph.
* of/commit-reach-repo-awareness:
commit-reach: parse commits in the given repository
The HTTP transport has been taught to check the revocation status of
the server certificate using the stapled OCSP response during the
TLS handshake via a new 'http.sslVerifyStatus' configuration
variable.
* gg/http-ssl-verify-status:
http: add http.sslVerifyStatus to check stapled OCSP responses
The 'Makefile' has been taught to precompile 'git-compat-util.h' to
speed up overall compilation, while excluding sources that do not
include the compatibility header.
* sg/precompile-git-compat-util:
Makefile: precompile "git-compat-util.h"
Makefile: reintroduce REFTABLE_OBJS
cmake: remove any "$(*_OBJS)" variables when parsing Makefile for sources
Makefile: remove XDIFF_OBJS initialization
The build-time knob 'USE_NSEC' for nanosecond stat precision has been
converted to a runtime configuration 'core.useNanosec', allowing
distributions to bundle one binary that adapts to filesystem
capabilities dynamically.
* dk/use-nsec-runtime:
core: convert build-time USE_NSEC into runtime core.useNanosec
environment: align repo_config_values_init with struct declaration
meson: expose knob for xmlto relative links in manuals
The terminology regarding reference storage formats has been unified
across command-line options, environment variables, configuration
variables, and source code, standardizing on the phrase "ref storage
format" (e.g., `--ref-storage-format`, `'GIT_REF_STORAGE_FORMAT'`).
Additionally, the `--ref-storage-format` option has been updated to
accept payloads in the form `<format>://<payload>`.
* ps/ref-storage-format:
setup: allow "--ref-storage-format=" to specify a payload
setup: rename "init.defaultRefFormat" to "init.defaultRefStorageFormat"
t: rename GIT_TEST_DEFAULT_REF_FORMAT
setup: rename ref storage format environment variables
setup: refactor how we configure the ref storage format
refs: expose function to parse reference URIs
help: rename "default-ref-format" to "default-ref-storage-format"
builtin/rev-parse: rename "--show-ref-format" to "--show-ref-storage-format"
builtin/submodule: rename "--ref-format=" to "--ref-storage-format="
builtin/refs: rename "--ref-format=" to "--ref-storage-format="
builtin/clone: rename "--ref-format=" to "--ref-storage-format="
builtin/init: rename "--ref-format=" to "--ref-storage-format="
parse-options: allow for hidden aliases
The files backend has been updated to avoid unconditionally locking
the 'packed-refs' file when deleting a root ref (which are never
packed).
* ak/refs-files-root-ref-lock:
refs/files: avoid packed-refs lock for root ref deletion
Updates to Coccinelle semantic patches to correctly handle the
'FREE_AND_NULL()' macro and avoid generating broken transformations
for negated pointer checks.
* jc/cocci-free-updates:
cocci: FREE_AND_NULL(E) is safe to call on NULL
cocci: remove risky "if (!E) free(E)" conversion
A new hook 'report' is added to 'git receive-pack', which runs after
reference updates and allows the server to filter or modify the
packet-line status report sent back to the client.
* kn/receive-report-hook:
receive-pack: coccinelle fix
hook: introduce the receive-report hook
receive-pack: move message generation to separate function
receive-pack: drop static variables to track report status version
doc: add proc-receive hook info in 'git-receive-pack.adoc'
The experimental 'git history' command has been taught a new 'squash'
subcommand to fold a range of commits into a single commit, with any
descendants replayed on top.
* hn/history-squash:
history: support editing squashed commit messages
history: create squashed commits without editing
history: protect branches when squashing a range
history: validate squash revision ranges
history: add skeleton for squash subcommand
sequencer: share the squash message marker helpers and flags
history: give commit_tree_ext a message template
history: extract helper for a commit's parent tree
The setup of alternates has been deferred to object database
creation time during clone, which drops the unused ad-hoc alternate
writing API, simplifying the object database backend interface.
* ps/odb-alternates-at-creation:
odb/source: remove the ability to write alternates
builtin/clone: write alternates via `odb_create_on_disk()`
odb/source: support writing alternates when creating the database
builtin/clone: move setup of alternates for non-shared local clones
builtin/clone: move setup of alternates for shared local clones
builtin/clone: refactor handling of "--reference{,-if-able}"
builtin/clone: move around `setup_reference()`
builtin/clone: defer setup of the object database
setup: split up concerns of `init_db()`
The `--show-objects` mode of `read_midx_file()` uses the output of
`midx_fill_entry()` without checking whether the lookup succeeded. A
failed lookup or unavailable pack can leave that output unusable,
allowing malformed or concurrently changed MIDX data to make this test
helper crash instead of reporting a controlled error.
Reject the entry unless `midx_fill_entry()` returns `MIDX_FILL_HIT`. The
unchecked call was introduced by 86d174b724
(t/helper/test-read-midx.c: add '--show-objects', 2021-03-30); later
incremental-MIDX changes expanded the possible failure modes, but this
remains a test-helper robustness issue, not a production Git attack
surface or an arbitrary-code-execution vulnerability.
It is unclear why Coverity reports this issue in Git for Windows only
after merging v2.56.0-rc0; The issue was not reported before.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The reftable fuzzer introduced by adf45165e6 (oss-fuzz: add fuzzer for
parsing reftables, 2026-07-03) ignored failures from
`reftable_table_init_ref_iterator()` and
`reftable_table_init_log_iterator()`. Coverity reported that under
allocation failure, either constructor can return
`REFTABLE_OUT_OF_MEMORY_ERROR` without installing an ops table, allowing
a subsequent seek to dereference NULL.
Treat iterator initialization failure as a reason to skip the
corresponding seek and iteration while retaining safe destruction for an
uninitialized iterator.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Coverity pointed out that the
`test_reftable_table__seek_invalid_log_offset()` test, which was
introduced by a1c085df8d (reftable/table: fix NULL pointer access when
seeking to bogus offsets, 2026-07-03), ignores the result of
`reftable_table_init_log_iterator()` and proceeds to
`reftable_iterator_seek_log()`, although initialization can return
`REFTABLE_OUT_OF_MEMORY_ERROR` without installing an ops table. Under
allocation failure, the test then dereferences a NULL function table.
Assert successful iterator initialization before seeking.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`rerere` can mark a conflict variant as resolved even when writing its
preimage or postimage fails. A later invocation may then replay
incomplete data from the cache, turning a local filesystem failure into
an incorrect working-tree change.
629716d256 (rerere: do use multiple variants, 2015-07-30) introduced
the code paths without checks for those I/O results. Treat such failures
as failures, report them, and leave the rerere status unchanged unless
the corresponding data was recorded successfully.
The defect has been latent since 2015. Git for Windows' Coverity run
only reported it after merging v2.56.0-rc0, for reasons that could not
be figured out in a reasonable amount of time.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Incremental MIDX support made object-offset pack IDs local to each layer
and then converted them to chain-global IDs by adding
`num_packs_in_base`. The conversion was introduced by 19419821ba
(midx: teach `nth_midxed_pack_int_id()` about incremental MIDXs,
2024-08-06). Chain-aware pack preparation followed in 1820bd878c
(midx: teach `prepare_midx_pack()` about incremental MIDXs, 2024-08-06),
but the final `midx_fill_entry()` lookup remained tied to the original
layer. Only with 8f909ff4e9 (packfile: recover when a multi-pack-index
names a removed pack, 2026-08-29) did Coverity point out this issue: a
local ID such as `UINT32_MAX` could wrap when the base-pack count was
added, producing a plausible but incorrect global ID. After
`prepare_midx_pack()` resolved the chain, `midx_fill_entry()` could then
underflow or address the wrong layer while indexing the current layer's
pack array, causing an invalid memory access and crashing Git.
Validate each local pack ID against its layer's pack count before adding
the base count, and obtain the final pack through `nth_midxed_pack()`,
which resolves the correct MIDX layer. This prevents an invalid local ID
from wrapping during conversion and ensures that the lookup uses the
layer identified by the resolved chain-global ID.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After merging v2.56.0-rc0 into Git for Windows, its Coverity run
reported the following issue: The `parse_signed_buffer()` function
accepts object buffers with an explicit size, while
`get_format_by_sig()` uses `starts_with()`, i.e. it expects a
NUL-terminated buffer. A tag object with a non-NUL-terminated payload
ending in a partial signature prefix, such as a final '-' byte, could
therefore cause an invalid read past the object buffer.
The observable consequences are limited to reading past the allocation.
In practice it can crash Git if the read enters an unmapped page. It can
also misplace the payload/signature split, corrupting the compat-hash
object being written.
The older unbounded matcher predates this path, but c8762c30df
(object-file-convert: convert tag objects when writing, 2023-10-01)
exposed the defect by passing exact-sized converted tag buffers to
`parse_signed_buffer()`. That commit first shipped in v2.45.0, so the
defect has been latent in every release since.
This pattern was noticed on the mailing list in February 2024. Reviewing
a patch for a very similar issue in commit.c's find_header_mem(), Jeff
King observed in
https://lore.kernel.org/git/20240208214137.GB1090198@coredump.intra.peff.net/:
But more interestingly: even though we pass a buf/len pair to
parse_signed_buffer(), it then calls get_format_by_sig() which takes
only a NUL-terminated string. [...] That raises the question of
whether parse_signed_buffer() has a similar walk-too-far problem. ;)
The answer is no, because we feed it from a strbuf. But it's not a
great pattern overall.
That reasoning surveyed the callers that existed at the time and missed
c8762c30df (object-file-convert: convert tag objects when writing,
2023-10-01), which was four months old at that time, and does not feed
from a strbuf; `convert_tag_object()` hands `parse_signed_buffer()` an
exact-sized `xmalloc()` buffer, and the concern flagged and dismissed in
that thread is exactly the defect Coverity now reports.
Jeff went on to add `starts_with_mem()` a month later, in
https://lore.kernel.org/git/20240307092638.GK2080210@coredump.intra.peff.net/,
precisely for "cases where the buffer is not NUL-terminated (and we
instead have an explicit size or end pointer)", so the tool for this fix
has been in the tree since v2.45.0.
Even though the issue had been latent, it most likely surfaced via
Coverity because of 215d305f45 (odb: compute compat object ID in
`odb_write_object_ext()`, 2026-07-17), which moved
`convert_object_file()` out of the `source->write_object` function
pointer into a direct call in `odb_write_object_ext()`.
Preserve the existing NUL-terminated behavior for callers that provide
strings while making signature-prefix matching honor the known buffer
lengths, via the `starts_with_mem()` helper. This keeps reads within the
object data without implying exploitability beyond the observed invalid
read.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As Git for Windows' Coverity run after merging v2.56.0-rc0 reported,
`writev_in_full()` keeps its cumulative successful output in an
`ssize_t`. Although `xwritev()` limits each individual write to a
syscall-sized amount, repeated successful writes can still exceed
`SSIZE_MAX`. The unchecked accumulation was introduced by d70eb7f360
(wrapper: introduce writev(3p) wrappers, 2026-08-07).
Treat an aggregate that would overflow the signed total as an I/O
failure.
Assisted-by: GPT-5.6 Luna
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The pathspec matching logic has been updated to avoid out-of-bounds
memory accesses when a negative pathspec is shorter than the common
prefix of positive pathspecs.
* yt/pathspec-negative-prefix:
dir: preserve pathspec prefix optimization with leading excludes
dir: do not apply prefix to negative pathspecs
Doc updates.
* tz/doc-pack-refs-and-refs-fixes:
doc/refs: backtick-quote commands and options consistently
doc/pack-refs: convert synopsis and options to new style
Normalize name formatting and map older formats to the canonical one.
Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a server enables uploadpack.allowRefInWant, upload_pack_v2()
sends wanted-ref info before shallow-info. The fetch-pack client
expects shallow-info first; receiving them out of order causes it
to exit:
fatal: expected 'packfile', received 'shallow-info'
This error condition only applies to protocol v2 clients performs
a shallow fetch (--depth) against servers with allowRefInWant
configured.
Swap the send order so that upload_pack_v2() sends shallow-info
before wanted-ref info. This is a server-side-only change and is
compatible with all existing client versions.
Signed-off-by: Royce Remer <royceremer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`can_all_from_reach()` and `can_all_from_reach_with_flag()` parse the
commits they walk in `the_repository`, even though their caller may be
working in a different repository. `repo_is_descendant_of()` is such a
caller: it is told which repository to work in, but as soon as
generation numbers are enabled it hands the commits over to
`can_all_from_reach()`, which then parses them elsewhere.
This breaks merging a superproject whose submodule pointer advanced on
both sides. merge-ort resolves it by calling `repo_in_merge_bases()` on
the submodule, and with a commit-graph in both the superproject and the
submodule the merge dies:
$ git merge side
fatal: invalid commit position. commit-graph is likely corrupt
`merge_submodule()` looks the submodule commits up in the submodule, so
walking their ancestry pulls in parents whose commit-graph position was
recorded while reading the submodule's commit-graph. The walk then
parses those parents in `the_repository`, where the recorded position
indexes the superproject's commit-graph instead: `fill_commit_graph_info()`
dies when the position is out of bounds, and quietly returns another
commit's date, generation and parents when it is not.
The latter used to be the only symptom. Before bb5da75d61 (commit: use
commit graph in `lookup_commit_reference_gently()`, 2026-02-16) the
initial lookup did not record commit-graph positions, so the walk simply
failed to find the submodule commits in the superproject:
error: Could not read <commit>
Failed to merge submodule sub (commits don't follow merge-base)
Pass the repository into both functions. git-fetch-pack(1) and
git-upload-pack(1) keep passing `the_repository`.
Reported-by: Florian Schmidt <flosch@nutanix.com>
Signed-off-by: Orestis Floros <orestisflo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The memory leak caused by not unusing the commit buffer returned by
repo_logmsg_reencode() during the rewording operation in 'git
history' has been plugged.
* ks/history-commit-leakfix:
builtin/history: unuse the commit buffer after use
When cross-compiling with Cargo, the output artifact is placed in a
target-specific subdirectory, which causes the build system to fail
to locate it. The build system has been updated to respect the
'CARGO_BUILD_TARGET' environment variable.
* jc/rust-cargo-build-target:
rust: respect CARGO_BUILD_TARGET when locating build output
Update Windows CI build to support Rust.
* js/rust-in-windows-ci:
ci(windows): build with Rust
rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
git never sets CURLOPT_SSL_VERIFYSTATUS, so libcurl never requests the
OCSP "Certificate Status Request" extension and any stapled response a
server sends is ignored, including responses that explicitly state the
certificate has been revoked.
Add an http.sslVerifyStatus boolean that maps to
CURLOPT_SSL_VERIFYSTATUS. http_options() is already the collect_fn for a
urlmatch config, so the per-URL form works with no changes:
git config http.https://example.com/.sslVerifyStatus true
Defaults to false/"off". This is due to the nature of the OCSP protocol.
If enabled, git would expect to receive OCSP stapled responses. If the
stapled responses were not present, the connection would be blocked as
the status of the server's certificate could not be verified. This would
break connections to legitimate services that don't use OCSP as their
certificate revocation mechanism.
If the backend can't check the staple, curl_easy_setopt() returns
CURLE_NOT_BUILT_IN. The error message includes curl_easy_strerror()
along with the option name, so a libcurl built without status
verification is easy to identify.
CURLOPT_SSL_VERIFYSTATUS has existed since libcurl 7.41.0, below our
7.61.0 floor, so no version guard is needed.
The tests that need no OCSP infrastructure stay in t5551, which t5559
runs over https. The rest need a certificate authority, a responder to
answer for it and a server configured to staple, so lib-httpd gains an
opt-in LIB_HTTPD_OCSP mode and t5585 uses it to check that a "good"
staple is accepted, a "revoked" one is refused, and that the revoked one
is ignored when the option is off.
Signed-off-by: Grayson Gordon <graysongordon1@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The consistency checks for the object database (fsck) have been
decoupled from the generic builtin implementation and moved into the
backend-specific object source layers, making them pluggable for
different object storage formats.
* ps/odb-pluggable-fsck:
builtin/fsck: move loose object verification into the loose source
builtin/fsck: move multi-pack index verification into the packed source
builtin/fsck: move bitmap verification into the packed source
builtin/fsck: move reverse index verification into the packed source
builtin/fsck: move packfile verification into the packed source
odb: provide infrastructure for pluggable fsck checks
builtin/fsck: don't check alternates with "--no-full"
builtin/fsck: de-globalize option handling
builtin/fsck: merge `fsck_obj_buffer()` and `fsck_obj()`
builtin/fsck: use `fsck_obj_buffer()` when checking loose objects
The mechanism to register in-memory alternate object sources has
been removed, as submodule object databases are now accessed
natively via their own repository structures. This simplifies
object database management and prepares the codebase for migrating
alternate tracking into the files backend.
* ps/odb-stop-registering-in-memory-sources:
odb: remove the ability to link sources ad-hoc
t/helper: stop registering alternates in "ref-store" command
t/helper: adapt read-midx to not link ad-hoc source anymore
builtin/multi-pack-index: refuse unknown sources with "--object-dir="
odb/packed: fix memory leaks when freeing source
tmp-objdir: drop unused function to register alternate
odb: remove infrastructure to register submodule sources
builtin/grep: stop registering submodule ODB as source
submodule-config: stop registering submodule sources
submodule-config: stop using `the_hash_algo`
submodule-config: remove uses of `the_repository`
cache-tree: remove dependency on `the_repository`
cache-tree: drop `the_repository` in `cache_tree_fully_valid()`
Windows build switches from MINGW64 to URCR64 runtime starting Git
2.56.0; switch the cmake based build at the same time.
* js/win-cmake-use-ucrt64:
cmake(windows): accommodate for Git for Windows' migration to UCRT64
Correct tests that depend on Perl running on MinGW
* js/mingw-test-fixes-around-perl:
t9129: skip UTF-8 tests on Windows
t9700: accommodate for MSYS2 Perl reporting as `cygwin`
The git-refs doc was converted to the synopsis style in 89be7d2774
(builtin/refs: add '--no-reflog' flag to drop reflogs, 2025-02-21). The
commands and options were not backtick-quoted at that time. 84f3d6e11e
(doc lint: check that synopsis manpages have synopsis inlines,
2025-08-11) applied backtick-quotes to the existing commands and
options.
Subsequently, a number of commands and options were added without such
quoting, leaving the documentation rendered inconsistently. Apply
backtick-quotes to all entries.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace [verse] with [synopsis] in the SYNOPSIS block and remove
single-quote formatting from the command name.
Backtick-quote all option terms in the OPTIONS section via the included
pack-refs-options.adoc and convert the standalone placeholder _<branch>_
in prose.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Every call to repo_logmsg_reencode() must be paired with a call to
repo_unuse_commit_buffer(), or we may leak an allocated buffer. We
have such a leak in "git history", which we can fix by adding an unuse
call.
The leak-checking tests don't detect this because we only allocate a
fresh buffer sometimes: when the message is reencoded, or when we had
to load it fresh from the odb (e.g., because the commit was parsed
from the commit graph rather than the object contents). But you can
see it by running:
make SANITIZE=leak
cd t
GIT_TEST_COMMIT_GRAPH=1 ./t3451-history-reword.sh
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch follows the idea of 671df48df8 (meson: precompile
"git-compat-util.h", 2026-03-19) to make it faster to build Git using
"make". The notable differences are the boilerplate needed to wire up
the precompiled header with "make", and the selection of object files
that are built using the precompiled header:
- Add a new rule to precompile "tools/precompiled.h" into
"tools/precompiled.h.gch".
This rule and its dependencies are basically the same as our
existing rule and its dependencies for compiling object files from
our source files and, except that in this rule we don't use the
EXTRA_CPPFLAGS target-specific variable. This is partly because
any compiler flags in that target-specific variable can't possibly
make sense for the project-wide "git-compat-util.h", and partly
because it could run afoul of "make"'s quirks with target-specific
variables and GCC's "-Winvalid-pch" compiler option [1].
Our Makefile always writes object files next to the source files
they were compiled from. Since a precompiled header is in many
ways similar to an object file, let's follow suit and write it
next to the header file it was created from as well. 671df48df8
doesn't mention why "precompiled.h" was placed in "tools/".
Use the ".gch" suffix for the precompiled header file, because
that's the only suffix GCC looks for when searching for a
precompiled header. Clang apparently looks for both ".pch" and
".gch" suffixes. If we ever encounter a compiler which only
supports a different precompiled header suffix, then we might make
the suffix configurable via a Makefile knob; but until then it
remains hard-coded for the sake of simplicity.
- Declare the precompiled header's dependencies, so it gets rebuilt
when any of our header files it includes is modified.
When using computed header dependencies, then the compiler can
generate the Makefile snippet containing the header files inlcuded
by the precompiled header, just like when compiling a C source
file into an object file.
When not using computed header dependencies, then make the
precompiled header depend on the same header files that our object
files depend on, i.e. those listed in LIB_H and GENERATED_H. This
is not ideal, because the precompiled header will be rebuilt even
when a header file it doesn't actually depend on changes; but in
that case all object files will be rebuilt as well anyway.
- List the object files that are built using the precompiled header
in the PRECOMPILED_HEADER_USERS variable:
- The precompiled header should not change what actually gets
compiled. Therefore, use the precompiled header only when
compiling source files that start with including
"git-compat-util.h" (directly or indirectly, e.g. via
"builtin.h"), or its inclusion is only preceeded by #define
directives that don't influence "git-compat-util.h" between its
include guards [2] (currently DISABLE_SIGN_COMPARE_WARNINGS,
USE_THE_REPOSITORY_VARIABLE or GIT_TEST_PROGRESS_ONLY). [3]
Several (but not all) object or source files listed in the
COMPAT_OBJS, REFTABLE_OBJS and THIRD_PARTY_SOURCES variables
don't include "git-compat-util.h", therefore, for the sake of
simplicity, none of the files listed in these variables are
built with the precompiled header. [4]
Since 671df48df8 the Meson build uses the precompiled header
even when compiling those reftable source files that don't
include "git-compat-util.h" at all, although this change is not
mentioned in the commit message.
- But other than that, use the precompiled header when compiling
all other source files, including e.g. source files for
standalone executables (e.g. "daemon.c" for "git-daemon"), or
those in the directories "t/helper/" and "t/unit-tests/" as
well.
The Meson build, however, only uses the precompiled header for
compiling objects in "libgit_sources" and "builtin_sources",
despite 671df48df8 giving the impression that the precompiled
header is included in all compilation units.
- In short, PRECOMPILED_HEADER_USERS contains all object files
listed in OBJECTS, except those that are listed in COMPAT_OBJS,
REFTABLE_OBJS or THIRD_PARTY_SOURCES as well.
- Add a new rule to build object files listed in
PRECOMPILED_HEADER_USERS with the precompiled header.
This rule and its dependencies are basically the same as our
existing rule and its dependencies compiling object files from our
source files, except:
- This rule depends on the precompiled header as well, to make
sure that it's built before it is used.
- Use the "-include tools/precompiled.h" option to make the
precompiled header the first header in the compilation unit,
because only then is it used to speed things up.
- Use the "-Winvalid-pch" option to catch any issues when the
precompiled header is present but can't be used for whatever
reason. While being unable to use the precompiled header would
normally only result in a slower build, it is probably better
that developers are made aware that simething is not quite
right. Meson uses this option as well when compiling a source
file using the precompiled header.
Note, that in case of such an issue with "-Winvalid-pch" we
would get a warning for each object file that is build using the
precompiled header, but together with "-Werror" (e.g. with
DEVELOPER=1) it would fail the build.
Object files not listed in PRECOMPILED_HEADER_USERS are built with
the existing (and unchanged) rule for object files.
- This way the precompiled header is compiled only once during
the whole build process.
The Meson build, however, currently compiles the precompiled
header twice: once for "libgit_sources" and once for
"builtin_sources", despite 671df48df8 giving the impression that
it's compiled only once. And, by the looks of it, it would have
to be compiled once more for each new library or executable where
we declare the use of the precompiled header.
- Add the Makefile knob NO_PRECOMPILED_HEADER to make it possible to
build without using the precompiled header for testing purposes,
or for any compiler that might be out there that doesn't support
the "-Winvalid-pch" option.
Note, that when this knob is set then we merely leave
PRECOMPILED_HEADER_USERS empty: this way nothing is built with the
precompiled header, but "make clean NO_PRECOMPILED_HEADER=1" would
still remove a leftover precompiled header file.
With this patch series on top of v2.55.0 I got the following build
time improvement:
Benchmark 1: make -j12 (rev = v2.55.0)
Time (mean ± σ): 29.414 s ± 0.031 s [User: 254.786 s, System: 47.447 s]
Range (min … max): 29.370 s … 29.470 s 10 runs
Benchmark 2: make -j12 (rev = precompile)
Time (mean ± σ): 21.725 s ± 0.047 s [User: 186.047 s, System: 35.109 s]
Range (min … max): 21.643 s … 21.768 s 10 runs
Summary
'make -j12 (rev = precompile)' ran
1.35 ± 0.00 times faster than 'make -j12 (rev = v2.55.0)'
[1] "make" applies target-specific variables to the first target's
dependencies as well. So, if the rule creating the precompiled
header included $(EXTRA_CPPFLAGS) as well, then we could get this:
$ make -s clean
$ make V=1 git
gcc -o tools/precompiled.h.gch -c -MF [...] -DSHELL_PATH='"/bin/sh"' '-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' '-DGIT_INFO_PATH="share/info"' tools/precompiled.h
gcc -o git.o -c -include tools/precompiled.h -Winvalid-pch -MF [...] -DSHELL_PATH='"/bin/sh"' '-DGIT_HTML_PATH="share/doc/git-doc"' '-DGIT_MAN_PATH="share/man"' '-DGIT_INFO_PATH="share/info"' git.c
gcc -o builtin/add.o -c -include tools/precompiled.h -Winvalid-pch -MF [...] -DSHELL_PATH='"/bin/sh"' builtin/add.c
cc1: error: ./tools/precompiled.h.gch: not used because `GIT_MAN_PATH' not defined [-Werror=invalid-pch]
cc1: all warnings being treated as errors
make: *** [Makefile:2940: builtin/add.o] Error 1
So in this case "git.o" is the first object file to be build, and
since it has a target-specific EXTRA_CPPFLAGS and since it depends
on the precompiled header, the precompiled header is built with
the same EXTRA_CPPFLAGS as well. But then "builtin/add.o" is
built with empty EXTRA_CPPFLAGS, and GCC's sanity checks for the
-Winvalid-pch option complain. Clang apparently doesn't consider
this to be an issue, and builds "git" just fine.
Note, however, that if the first object file to be built is not
"git.o" (or one of the other object files with target-specific
EXTRA_CPPFLAGS), which is usually the case with e.g. "make all",
then the precompiled header is built with empty EXTRA_CPPFLAGS,
and then all is well. Weird. We already had issues with "make"
and target-specific variables in the past, see a673cfede6
(Makefile: Fix occasional GIT-CFLAGS breakage, 2010-03-19).
The Meson build doesn't use target-specific variables, and the
whole project needs to be rebuilt when e.g. "mandir" is changed,
although this is not mentioned in 904339edbd (Introduce support
for the Meson build system, 2024-12-06).
[2] See baa61e46da (git-compat-util.h: move warning infra to prepare
for PCHs, 2026-03-19).
[3] This can be verified by simply scanning through the output of:
{
printf '%s\n' 'print-%:'
printf '\t%s\n' '@printf "%s\n" $($*)'
} >/tmp/printvars.mak
for f in $(make -f /tmp/printvars.mak -f Makefile print-PRECOMPILED_HEADER_USERS)
do
f="${f%o}c"
sed -n -E -e "s%# *(define|include).*%& $f%p" -e '/# *include/q' "$f"
done | sort
[4] "make"'s flexibility would allow us to separately list those
object files that don't include "git-compat-util.h", but then on
my (I assume fairly typical) Linux box the number of object files
built using the precompiled header increases only by 9 (from 536
to 545), which reduces the build time by about 1% (0.2s).
Therefore, I don't think it's worth the churn.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the next commit we are about to precompile "git-compat-util.h" with
"make" to reduce build times. But using the precompiled header should
not change what actually gets compiled, therefore a source file can
only be compiled using the precompiled header if the first included
header file is "git-compat-util.h".
The reftable source files are kind of special, because the reftable
implementation is supposed to be easily includable in other projects.
Therefore, the reftable source files don't include
"git-compat-util.h", with the sole exception of the purposefully
project-specific "reftable/system.c". Consequently, they shouldn't be
compiled with our precompiled header.
List object files under "reftable" in the REFTABLE_OBJS Makefile
variable, so in the next commit we'll be able to easily filter them
out and keep building them the old way, without the precompiled
header.
Note that object files under "reftable/" used to be listed in
REFTABLE_OBJS so we could build a static library from them. This
static library was removed in f3b4c89d59 (make: delete REFTABLE_LIB,
add reftable to LIB_OBJS, 2025-10-02), along with filling
REFTALBE_OBJS with object files. This change essentially reverts the
removal of REFTABLE_OBJS, but not the building of that static library.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To get various lists of files, CMake parses our Makefile looking for
lines matching e.g. "list_var += ...". In case of LIB_OBJS this
picks up the line "LIB_OBJS += $(COMPAT_OBJS)" as well, so the parsing
macro has a specific instruction to remove "$(COMPAT_OBJS)" from the
resulting list.
Currently this is the only such Makefile variable to be removed from
the list, but the next patches will (re)introduce more variables
containing lists of object files, so let's generalize that removing
instruction to remove any "$(*_OBJS)" Makefile variable as well.
Note that we can't make the pattern matching the Makefile variable too
general, e.g. to match any "$(VARIABLE)", because some lines of our
Makefile do contain variables as directory prefixes, e.g.
"UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o", and we must
definitely keep those.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Object files under 'xlib/' used to be listed in the XDIFF_OBJS
Makefile variable so we could build a static library from them. This
static library was removed in cf680cdb95 (make: delete XDIFF_LIB, add
xdiff to LIB_OBJS, 2025-10-02), along with filling XDIFF_OBJS with
object files.
But the initial empty initalization of XDIFF_OBJS remained, so remove
it now.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let's not check the nullness of cmd->error_string_owned before
calling FREE_AND_NULL(cmd->error_string_owned). It is cheap and
safe to call FREE_AND_NULL(variable) for a variable that has NULL
in it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git rev-list command has been augmented with a '--missing-only'
option that filters the output to only show missing objects,
stripping the leading '?' character and suppressing present objects,
which is useful when used in combination with '--missing=print' or
'--missing=print-info'.
* sa/rev-list-missing-only:
rev-list: add --missing-only option to filter output
"git maintenance" triggered "rerere gc" in unappropriate times and
interfered with "git rebase" etc. too much. The conditions "rerere
gc" gets triggered have been tweaked.
* ps/tune-rerere-gc:
builtin/maintenance: improve heuristic for "rerere gc"
rerere: extract logic to determine whether entries are stale
Junio C Hamano