The 'git range-diff' command has been augmented with a
'--matched-only' option to skip commits that are only present on
one side, allowing users to easily focus on only the commits that
have been retained.
* hn/range-diff-matched-only:
range-diff: add --matched-only to skip one-sided commits
The `git multi-pack-index write` command has been updated to
silently return success when there are no object entries to index.
This avoids writing empty `multi-pack-index` layers, which
previously caused subsequent incremental midx writes using the
`--bitmap` option to fail when attempting to load the missing
reverse index.
* pp/midx-write-skip-empty:
midx-write: skip writes with no object entries
The external merge driver in 'git merge' now uses the tempfile API
to create its temporary files. This ensures that these temporaries
are reliably cleaned up even when the merge driver or its parent Git
process is terminated abruptly.
* jk/merge-ll-tempfile-cleanup:
merge-ll: use tempfile API for external driver files
merge-ll: catch close() errors when writing external tempfiles
merge-ll: use strbuf to read back external merge result
A new linter test has been added to Documentation/lint-manpages.sh
to ensure that all non-command manual pages (guides and developer
interfaces) listed in Documentation/Makefile are present in
command-list.txt, replacing an older comment that reminded
developers to keep them in sync.
* ta/command-list-guides-sync-lint:
lint-docs: check the guide list in command-list.txt
command-list.txt: add gitformat-loose(5) and gitpacking(7)
The git config --global read operations have been updated to respect
both $HOME/.gitconfig and $XDG_CONFIG_HOME/git/config, fixing an
inconsistency where only the former was read when both configuration
files are present.
* dw/config-read-both-global:
config: read global scope via config_sequence
config: let sequence require a successful file
path: use forward slashes in XDG config on Windows
The --recurse-submodules option in 'git branch' has been fixed to
avoid a crash when the start point is not a reference (e.g., a raw
object ID). The creation path now skips setting up tracking and
properly forwards the absent tracking name to the submodule helper.
* vv/branch-recurse-no-start-ref:
branch: allow recursion with no tracking name
branch: do not track a start point with no ref
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
'git pull' has been taught to fail more gracefully instead of
segfaulting when lookup_commit_reference() fails on unparseable
objects.
* jk/pull-null-merge-head:
pull: avoid segfault when commit lookup fails
The Windows GitLab CI job has been updated to provision and use the
GNU Rust toolchain for MinGW builds, fixing job failures caused by
incomplete Rust setup and missing linker support.
* js/gitlab-ci-windows-rust:
ci(gitlab,windows): provide GNU Rust's host-linker support
ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
ci(gitlab,windows): preserve exclusions during dependency setup
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
A bug in git diff --no-index that mishandled reverse (-R) output
when conflicts existed between a file and a directory has been
fixed.
* hd/diff-no-index-reverse-fix:
diff --no-index: fix -R with file/directory conflicts
The error reporting machinery in the WinANSI compatibility layer has
been simplified to pass the exact Windows error code and correctly
format arguments for fatal errors.
* yt/winansi-die-lasterr-fix:
compat/winansi: fix die_lasterr() argument formatting
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 '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()`
get_can_ff() and already_up_to_date() pass the result of
lookup_commit_reference() straight to commit_list_insert() and
repo_is_descendant_of() without checking it. When the object
behind HEAD or one of the merge heads cannot be parsed, e.g. because
a loose object was left truncated by a fetch or gc racing on the
same repository, lookup_commit_reference() returns NULL and
"git pull" segfaults instead of reporting the corruption.
Treat a failed lookup as "cannot fast-forward" and "not up to date",
so that the caller falls through to the normal merge path, which
already diagnoses the broken object and fails cleanly.
An alternative would be to report the breakage at each lookup site,
which could give a more precise diagnosis. The minimal guards are
preferred because they do no more than is needed to avoid the
crash, and will be easy to drop once "git pull" is reworked to
resolve object names into commit objects early and pass those
around, at which point there will not be multiple lookups of the
same object name to guard in the first place.
The test corrupts the loose object in place rather than removing
it: a missing object that is still recorded in the commit-graph is
caught by the consistency check in fetch-pack before "git pull"
reaches the fast-forward check, so removing it would not exercise
the crash.
Signed-off-by: Jiri Kuncar <jiri.kuncar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During WinANSI initialization, duplicate_handle() reports the handle
when DuplicateHandle() fails. die_lasterr() collects the formatting
arguments in a va_list, but passes that va_list to die_errno() as an
ordinary variadic argument. die_errno() consequently formats part of
the va_list representation instead of the supplied handle, producing
an incorrect fatal message.
The helper also converts GetLastError() to errno, losing the exact
Windows error code.
Remove die_lasterr() and report GetLastError() directly at its four
call sites, following the existing Windows diagnostic style. This
passes the handle to the formatter correctly and preserves the Windows
error code. Keep the existing %li representation of the handle.
Helped-by: Johannes Sixt <j6t@kdbg.org>
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Yongqiang Tian <yqtian668@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking
gitcore's build script:
https://gitlab.com/dscho/git1/-/jobs/16593470275
Although gitcore is a static library, Cargo first links `build.rs`
as a host executable. We omitted the GNU MSI's `Gcc` feature, which
supplies the required linker and platform libraries:
https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GitLab's MinGW job fails with "cargo: command not found":
https://gitlab.com/git-scm/git/-/jobs/1657645018286909a94db (ci(windows): build with Rust, 2026-09-13) enabled Rust
in the shared CI configuration, but added the necessary setup only
for GitHub Actions.
The build needs Cargo to be reachable after the minimal SDK's login
profile replaces PATH. Installing the toolchain alone is not enough.
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Creating .git/info/exclude as a file with `New-Item` and `-Force`
truncates existing contents.
When install-dependencies.ps1 follows install-sdk.ps1, this discards
the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK
files as unignored build artifacts.
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The minimal Git for Windows SDK already supplies Git and GCC. The
MinGW Makefile build needs the GNU Rust toolchain, not another Git
installation or Meson.
Let the dependency installer serve this configuration while keeping
the existing package set for MSVC builds.
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a path is a file on one side and a directory on the other,
queue_diff() queues the file separately before recursing into the
directory. This early queue entry bypasses the reverse_diff handling
used for ordinary files.
As a result, comparing directories d and e where d/sub is a file and
e/sub/file is another file reports both paths as deleted with -R.
Reversing the operands reports both paths as added instead.
Swap the filespecs of the early queue entry when reverse_diff is set,
so that -R reverses the file change as well as the directory contents.
Add regression tests for both directions.
Signed-off-by: Haokai Ding <hk_ding@outlook.com>
Reviewed-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Junio C Hamano