Conversation
Finish incomplete sentence to say that we - build Git 2.55 by default with Rust, - but you can opt out and build 2.55 without Rust, - but Rust will become mandatory in Git 3.0 and later. Signed-off-by: Junio C Hamano <gitster@pobox.com>
The svn tests currently assume that git-svn's option parsing will always fail the tests because it exits 0 on --help, not 129. However, in a future commit, we'll expect it to exit 0 and the tests will then need to be updated to succeed in some cases and fail in others. We therefore need to have t1517 determine whether the Subversion Perl modules are present, since if they are not, git-svn will die on start and then it needs to continue to expect failure. Add a stripped down version of the tests in t/lib-git-svn.sh as a prerequisite we can use here for our svn tests. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we parse a command line option such as -h or --help, we currently exit 129, since that is the exit code when help output is printed. In a future commit, we'll change this to exit 0 instead, since we're doing what the user wanted successfully. However, there are some cases where we print help output because the user has provided ambiguous or invalid input, such as an ambiguous option, and we'll want to exit unsuccessfully there. Make this easier by defining a new return code, PARSE_OPT_HELP_ERROR, that can be used in this case, while reserving PARSE_OPT_HELP for those cases where the user has requested help directly. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The standard philosophy for Unix software when a help option (such as
--help) is specified is that the software should exit 0, printing the
help output to standard output, since the standard output is for
user-requested output and the program performed the requested task
successfully. If the user specifies an incorrect option, then the help
output should be printed to standard error (since the user has made a
mistake) and it should exit unsuccessfully.
git rev-parse --parseopt properly directs the output in both of these
cases, but it currently exits 129 when it receives a --help or -h option
on the command line, which causes its invoking script to do the same.
This is not in line with the usual behavior and it causes scripts using
this command to exit unsuccessfully on --help as well.
Note that Git subcommands implemented using scripts, such as git
submodule, don't have this problem because Git itself intercepts the
--help option and runs man (or a similar tool), which then exits 0.
However, this still affects the myriad scripts that use this
functionality because Git is widespread and the --parseopt functionality
is a good way to get sensible option parsing across shells in a portable
way.
Because git rev-parse --parseopt is intended to be eval'd by the shell,
when help output is to be printed to standard output, Git actually
prints a cat command with a heredoc since the standard output is being
evaluated by the shell. Thus, to do the right thing, simply add an
"exit 0" right after the end of the heredoc, which will cause the
invoking program to exit successfully.
The usual invocation recommended by the manual page is this:
eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
Thus, the fact that git rev-parse --parseopt still exits 129 in this
case is irrelevant, since the "echo exit $?" will print "exit 129", but
that will be after the "exit 0" printed by Git—and thus ignored, since
the shell will have already exited successfully.
Update the tests for this case. Note that we no longer need to delete
only the first and last lines in some tests, so add a command to delete
the end of the heredoc as well. We could do something clever with sed
to delete all but the last two lines or switch to head and tail, but
those would be more complicated and less readable, so just stick with
the simple approach.
In t1517, add three shell scripts to the failure case because they no
longer return 129 as expected. In a future commit, we'll change the
expected result to exit 0 and these will become successful again.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The standard philosophy for Unix software when a help option (such as --help) is specified is that the software should exit 0, printing the help output to standard output, since the standard output is for user-requested output and the program performed the requested task successfully. If the user specifies an incorrect option, then the help output should be printed to standard error (since the user has made a mistake) and it should exit unsuccessfully. Most of our commands currently exit 129 on receiving the -h option to print the short help, which does not line up with the standard philosophy above. Let's change that to exit 0 instead. This requires changes to a variety of tests which previously wanted the 129 exit code, so update them. Note that because git diff does its own option parsing, it still exits with 129, so update some of the tests to expect either exit status. Some commands also now pass with -h but not --help-all, so handle those cases differently for those commands. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We'd like to add more logic to git_hash_init(), but many callers skip it and call algop->init_fn() directly. Let's make sure we're consistently using the wrapper by adding a coccinelle rule. Besides the coccinelle file itself, this is a purely mechanical conversion based on the patch it generates. There should be no bare init_fn() calls left (except for the one in the wrapper). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous patch added a coccinelle rule to make sure callers always use git_hash_init() rather than direct function pointers from the algo struct. Let's do the same for the rest of the git_hash_*() wrappers. I split these out because they're a bit different: they implicitly use the algop pointer in the git_hash_ctx. So when we convert: -algo->update_fn(&ctx, buf, len); +git_hash_update(&ctx, buf, len); we drop the reference to algo entirely! But this is always going to be the right thing. If "algo" does not match what is in ctx.algop, then we'd already be invoking undefined behavior. So in addition to making it possible to add more logic to the git_hash_*() functions, we're avoiding the need to pass around the extra algo pointer and make sure that it matches what's in "ctx". The rest of the patch is the mechanical application of that coccinelle patch, plus a minor cleanup in test-synthesize.c to drop a now-unused function parameter (since we don't have to pass around the algo separately anymore). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want people to use the git_hash_*() wrappers rather than the bare
function pointers in the git_hash_algo struct. Let's document them
rather than the bare pointers, and warn people away from the pointers.
Coccinelle will eventually force the use of the wrappers, but it's
helpful to lead readers in the right direction from the start.
While we're here we can document a few other bits of wisdom I've turned
up while working in this area:
- You have to initialize the destination of a git_hash_clone(). This
is something we may eventually change for efficiency, but we should
definitely document the requirement for now.
- You must eventually finalize or discard a hash, since some backends
may allocate resources during initialization.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You must always either finalize or discard a hash context to release any
resources, but you must call only one such function. This creates extra
work for some callers, since their cleanup code paths need to know
whether they got there via their happy path (and the finalization
happened) or due to an error (in which case they need to discard).
Let's add an "active" flag that turns a redundant discard into a noop.
That lets you safely do this:
git_hash_init(&ctx, algo);
...
if (some_error)
goto out;
...
git_hash_final(result, &ctx);
out:
git_hash_discard(&ctx);
This should avoid future errors, and will also let us simplify a few
existing callers (in future patches).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that it is safe to call git_hash_discard() even after finalizing it, we can simplify our cleanup logic a bit. This is mostly undoing a few bits of 64337ae (csum-file: always finalize or discard hash, 2026-07-02): - We no longer need a separate free_hashfile_memory() function for finalize_hashfile(). It can just call free_hashfile(), which will now discard (or not) the hash as appropriate. - When f->skip_hash is set, we don't need to discard; we can rely on free_hashfile() to do it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that it is OK to call git_hash_discard() even after finalizing the hash, we no longer need the ctx_valid bool added by a2d8ea5 (http: discard hash in dumb-http http_object_request, 2026-07-02). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It only makes sense to call git_hash_update(), etc, on a hash context that has been initialized but not yet finalized or discarded. This is an unlikely error to make, but it's easy for us to catch it and complain. It's especially important because it would quietly "work" for many hash backends (like sha1dc, which is just manipulating some bytes) but would cause undefined behavior with others (like OpenSSL, which puts the context onto the heap). Checking the flag lets us catch problems consistently on every build. Note that we can't do the same for git_hash_init(). Even though it would cause a leak to call it twice (without an intervening final/discard), the point of the function is that the contents of the struct are undefined before the call. But calling it twice is an even less likely error to make, so not covering it is OK. We leave git_hash_discard() alone, as its idempotent behavior is convenient for callers. We _could_ try to do something similar for git_hash_final(), allowing: git_hash_final(result, &ctx); git_hash_final(other_result, &ctx); but it does not make much sense. After the first final() call we have thrown away the state, so we cannot produce the same output. We could come up with some sensible output (the null hash, or the empty hash), but double-calls like this are more likely a bug, so our best bet is to complain loudly (whereas the current code produces either nonsense output or undefined behavior, depending on the backend). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When Rust is enabled, the git-credential-osxkeychain helper depends on Rust symbols compiled into $(RUST_LIB). While commit 522ea8e ("osxkeychain: fix build with Rust") updated the linker command line to use $(LIBS), it omitted $(RUST_LIB) from the target prerequisite list. Without this prerequisite, running a parallel build ("make -j") from a clean working tree can fail because Make does not know to invoke Cargo to build libgitcore.a before linking git-credential-osxkeychain. Note that we depend explicitly on $(LIB_FILE) and $(RUST_LIB) rather than $(GITLIBS). Unlike standard Git builtins and programs like scalar (which define cmd_main() and rely on common-main.o to supply main()), git-credential-osxkeychain.c defines its own standalone int main(). If $(GITLIBS) were used, $(filter %.o,$^) in the link recipe would match both git-credential-osxkeychain.o and common-main.o, causing a duplicate symbol linking error for _main on macOS. Additionally, wrap the definitions of $(RUST_LIB) and the "rust" build target in "ifndef NO_RUST". This ensures that when NO_RUST=1 is specified, $(RUST_LIB) evaluates to empty, making the Rust dependency a clean no-op without needing intermediate variables. Signed-off-by: Shardul Natu <snatu@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On macOS, Universal Binaries contain native executable code for
multiple architectures (such as Intel x86_64 and Apple Silicon arm64)
bundled into a single file. This is standard practice for macOS
distribution and CI packaging (such as internal distribution packages
or tooling like Burrito/Homebrew), allowing a single build artifact
to run natively across all Macs without Rosetta emulation or
maintaining separate packages.
When building Git C code for multiple architectures on macOS, the
Apple toolchain (clang) natively supports universal builds via
CFLAGS/LDFLAGS. When "-arch x86_64 -arch arm64" is passed, clang
automatically compiles and links universal binaries for all C object
files and executables out of the box.
Cargo and rustc, however, do not support multiple "-arch" flags or
emitting universal binaries in a single invocation. Instead, Cargo
requires invoking each target triple independently (e.g., passing
"--target x86_64-apple-darwin" and "--target aarch64-apple-darwin").
To bridge this gap when Rust is enabled:
1. Allow specifying space-separated target triples in RUST_TARGETS.
2. Introduce declarative pattern rules (target/%/...) to compile
each target-specific library slice via Cargo.
3. On macOS, if multiple targets are specified, use "lipo" (part of
the mandatory Xcode Command Line Tools) to combine the resulting
static libraries into target/release/libgitcore.a.
Once $(RUST_LIB) is compiled into a universal static archive, the
standard C linker seamlessly links it with the C object files to
produce universal Git executables.
Signed-off-by: Shardul Natu <snatu@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "make test" with TEST_CONTRIB_TOO=yes (which is default in macOS CI workflows), $(MAKE) -C contrib/ test is invoked. However, contrib/Makefile only invoked tests for diff-highlight and subtree, meaning git-credential-osxkeychain was never built or verified during standard CI test runs. Add a "test" target to contrib/credential/osxkeychain/Makefile that depends on building git-credential-osxkeychain. Additionally, wire up credential/osxkeychain in contrib/Makefile under "all", "test", and "clean" whenever running on macOS (Darwin). This ensures that running "make test" or "make all" in contrib on macOS automatically builds and links git-credential-osxkeychain, preventing future build or symbol linking regressions from slipping through CI. Signed-off-by: Shardul Natu <snatu@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 3ad0ba7 ("git-submodule.sh: improve variables readability") made `git submodules update -i` pass `-i` as is to submodule--helper, but it fails with `error: unknown switch `i'` because the helper does not accept the short option. All other short options supported by git-submodule.sh are properly handle in the helper, so also add the alias for --init Fixes: 3ad0ba7 ("git-submodule.sh: improve variables readability") Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
While this document outlines an idealized lifecycle where an author develops a patch, refines it with reviewer feedback, and successfully merges it into Git, reality is rarely so seamless. Sometimes, a topic must be abandoned. Doing so explicitly is far better than leaving it in limbo, especially since topics can always be resurrected later. Clearly state that we encourage contributors to retract any topic that does not pan out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
On clone, when the client sends the `bundle-uri` command, the server
might respond with invalid data. For example if it sends information
about a bundle where the 'uri' is empty, it produces the following
error:
Cloning into 'foo'...
error: bundle-uri: line has empty key or value
error: error on bundle-uri response line 4: bundle.bundle-1.uri=
error: could not retrieve server-advertised bundle-uri list
This error is bubbled up to `transport_get_remote_bundle_uri()`, which
is called by `cmd_clone()` in builtin/clone.c. Over here, the return
value is ignored, so clone continues.
Despite this, it still dies with this error:
fatal: expected 'packfile'
This happens because `get_remote_bundle_uri()` exited early, leaving
some unprocessed packet data behind in the read buffer. This is
misleading to the user, because it suggests a problem with the packfile
exchange, when in reality it's caused by a misconfigured bundle-URI on
the server-side.
Fix this by continuing to read packets when an error was encountered,
but without processing the remaining lines. This drains the protocol
stream so no stale data is left behind and the caller can use it if they
like.
With this, clone now continues successfully if invalid bundle-URI data
was sent by the server. This is intentional, because since the inception
of `transport_get_remote_bundle_uri()` in 0cfde74 (clone: request the
'bundle-uri' command when available, 2022-12-22) the return value of
that function is ignored in `cmd_clone()` so the clone can continue
without bundles.
Signed-off-by: Toon Claes <toon@iotcl.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When bundle-URI info is requested by the client, the server responds
with all "bundle.*" config lines as key=value packet lines. On the
client-side, the received bundle config packet lines are always expected
to contain both a key and a value otherwise the client errors out during
parsing. The server performs no validation of the read bundle
configuration though which results in any misconfiguration on the
server-side, such as bundle configuration with an empty value, being
blindly sent to the client.
To avoid having the server transmit invalid configuration to clients,
only send bundle configuration that has non-empty values.
This change makes bundle-URI information sent by the server
syntactically correct, but semantically it still can be invalid. For
example the server may end up sending `bundle.bundle-1.creationToken`,
but be lacking a `bundle.bundle-1.uri` for that bundle. The `uri` is
mandatory, thus the client cannot process this bundle and will error
with the message:
error: bundle 'bundle-1' has no uri
Fixing this would require a more complex solution, because bundles need
to be validated as a whole and not line-by-line. This is considered
outside the scope of this change.
Co-authored-by: Toon Claes <toon@iotcl.com>
Signed-off-by: Justin Tobler <jltobler@gmail.com>
Signed-off-by: Toon Claes <toon@iotcl.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffing the working tree against a commit with a pathspec can take time quadratic in the size of the index when the pathspec matches a subtree whose entries are the first entries of the index. Fix it by having next_cache_entry() record how far it scanned in cache_bottom, so repeated calls no longer rescan the growing prefix of already-unpacked entries. On a Chromium checkout (~500k index entries), git diff HEAD -- .agents/OWNERS took about 8 minutes before this change and 0.07 seconds after it. The same diff without the commit, without the pathspec, or with --cached was already instant. Add p0009-diff-pathspec.sh, which builds a 10,000-entry index whose first path lives in a subtree (100,000 entries under --long-tests), to guard against the regression. Comparing v2.55.0 with this change using GIT_TEST_LONG=t: Test v2.55.0 HEAD ------------------------------------------------------------------------ 0009.2: diff pathspec subtree 7.16(7.12+0.01) 0.02(0.01+0.00) -99.7% Signed-off-by: Henrique Ferreiro <hferreiro@igalia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Piping git commands directly to wc -l suppresses the exit code of git, hiding potential failures from the test suite. Use test_stdout_line_count instead, which handles exit code preservation internally while keeping the test logic clean and readable. Signed-off-by: Gatla Vishweshwar Reddy <gatlavishweshwarreddy26@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Taylor Blau <ttaylorr@openai.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
…tory * ps/refs-writing-subcommands: builtin/refs: add "rename" subcommand builtin/refs: add "create" subcommand builtin/refs: add "update" subcommand builtin/refs: add "delete" subcommand builtin/refs: drop `the_repository`
* ps/odb-drop-whence: odb: document object info fields odb: drop `whence` field from object info treewide: convert users of `whence` to the new source field odb: add `source` field to struct object_info_source odb: make backend-specific fields optional packfile: thread odb_source_packed through packed_object_info()
Count the number of steps taken in compute_reachable_generation_numbers() and expose it via trace2 to make it easier to detect performance regressions. Add a failing test for such a regression, introduced in 199d452 (commit-graph: return the prepared commit graph from `prepare_commit_graph()`, 2025-09-04), where incremental commit-graph writes do not see existing generation numbers from lower graph layers and fall back to walking the full ancestry. Signed-off-by: Kristofer Karlsson <krka@spotify.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The topo_levels slab is only propagated to the topmost graph layer instead of all layers in the chain. Commits from lower layers appear to have no generation numbers, so the DFS re-walks the entire ancestry. Fix by making topo_levels visible to all layers, not just the first one. Signed-off-by: Kristofer Karlsson <krka@spotify.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The outer loop in `diffcore_merge_broken()` sets `q->queue[j]` to NULL when it merges a broken pair back together, and has a NULL check to skip such entries on subsequent iterations. The inner loop, however, lacks this guard: when it scans forward looking for a matching peer, it can encounter a slot that was NULLed by a previous outer-loop iteration and dereference it unconditionally. In practice this requires at least two broken pairs whose peers both survive rename/copy detection and appear later in the queue, which is rare but not impossible. Add the same `if (!pp) continue` guard to the inner loop. Pointed out by Coverity. Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `repo_get_commit_tree()` function can return NULL when a commit's tree object is not available (e.g., the commit was parsed but its maybe_tree field is unset and the commit is not in the commit-graph). In cmd_diff(), the return value is immediately dereferenced via ->object without a NULL check, which would crash if the tree cannot be loaded. Add an explicit NULL check and die with a descriptive message. Pointed out by Coverity. Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `remote_tracking()` function unconditionally dereferences
`remote->fetch` without checking whether remote is NULL.
In practice, this never happens because the only caller (`apply_cas()`)
guards the calls to this function by checking the `use_tracking` and
`use_tracking_for_rest` attributes.
However, it requires quite involved reasoning to reach that conclusion,
and is therefore fragile. Just return -1 ("no tracking ref") when there
is no remote to work with.
Pointed out by Coverity.
Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --graph' has been modified to visually distinguish parentless 'root' commits (and commits that become roots due to history simplification) by indenting them, preventing them from appearing falsely related to unrelated commits rendered immediately above them. * ps/shift-root-in-graph: graph: add --[no-]graph-indent and log.graphIndent graph: move config reading into graph_read_config() graph: wrap cascading commits after 4 columns graph: indent visual root in graph graph: add a 2 commit buffer for lookahead revision: add next_commit_to_show() lib-log-graph: move check_graph function
An accidental use of the '%zu' format specifier in 'git submodule--helper' has been corrected to use 'PRIuMAX' and cast the value to 'uintmax_t' to avoid portability issues. * jc/submodule-helper-avoid-zu: submodule--helper: avoid use of %zu for now
The ref subsystem and the worktree API have been refactored to pass a repository pointer down the call chain, allowing them to drop references to the global 'the_repository' variable. As part of this, the handling of the 'core.packedRefsTimeout' configuration has been moved into the per-repository ref store structure. * ps/refs-wo-the-repository: refs: remove remaining uses of `the_repository` worktree: pass repository to public functions worktree: pass repository to file-local functions worktree: refactor code to use available repositories refs/files: drop `USE_THE_REPOSITORY_VARIABLE` refs/packed: de-globalize handling of "core.packedRefsTimeout"
'git branch --contains' and 'git for-each-ref --contains' have been optimized to use the memoized commit traversal previously used only by 'git tag --contains', significantly speeding up connectivity checks across many candidate refs with shared history. * td/ref-filter-memoize-contains: commit-reach: die on contains walk errors ref-filter: memoize --contains with generations commit-reach: reject cycles in contains walk
The passing of push destination specifications in the 'remote-curl' helper has been simplified by removing the explicit 'count' parameter and relying on the NULL-termination of the array. * rs/remote-curl-simplify-push-specs: remote-curl: simplify passing of push specs
The dependency on the global 'the_repository' variable in the 'refspec.c' API has been removed by passing the hash algorithm explicitly to refspec-parsing functions and storing it in 'struct refspec'. * ps/refspec-wo-the-repository: refspec: stop depending on `the_repository` refspec: let callers pass in hash algorithm when parsing items refspec: group related structures and functions
The enumeration of untracked and ignored files in 'git status' has been optimized by avoiding quadratic complexity when inserting into string lists, reducing the construction cost from O(n^2) to O(n log n). * sc/wt-status-avoid-quadratic-insertion: wt-status: avoid repeated insertion for untracked paths
The copy_file() and copy_file_with_time() functions have been refactored to take a repository parameter, allowing the removal of the implicit dependency on the global 'the_repository' variable in 'copy.c'. * ps/copy-wo-the-repository: copy: drop dependency on `the_repository`
The rebase post-rewrite notes-copying logic has been corrected. When a commit is dropped during rebase (e.g., because its changes are already upstream), it is no longer recorded as rewritten, preventing its notes from being copied to an unrelated commit. * pw/rebase-drop-notes-with-commit: sequencer: do not record dropped commits as rewritten sequencer: use an enum to represent result of picking a commit sequencer: simplify pick_one_commit() sequencer: remove unnecessary condition in pick_one_commit() sequencer: simplify handling of fixup with conflicts sequencer: remove unnecessary "or" in pick_one_commit() sequencer: never reschedule on failed commit sequencer: be more careful with external merge t3400: restore coverage for note copying with apply backend
A few memory problems in the Rust interface to C hash functions have been corrected. The 'Clone' implementation of 'CryptoHasher' now properly initializes the context before cloning, and its 'Drop' implementation now discards the context to prevent leaks. * bc/rust-hash-cleanups: rust: discard hash context when finished hash: initialize context before cloning
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tempfile and lockfile APIs have been refactored to stop depending
on the 'the_repository' global variable, and their callers have been
updated to use the repository-aware variants.
* rs/tempfile-wo-the-repository:
use repo_hold_lock_file_for_update{,_mode,_timeout}() with custom repos
tempfile: stop using the_repository
lockfile: add repo_hold_lock_file_for_update{,_timeout}{,_mode}()
refs/packed: use repo_create_tempfile()
tempfile: add repo_create_tempfile{,_mode}()
The 'trust_executable_bit' (coming from the 'core.filemode' configuration) has been migrated into 'struct repo_config_values' to tie it to a specific repository instance. * ty/migrate-trust-executable-bit: environment: move has_symlinks into repo_config_values environment: move trust_executable_bit into repo_config_values read-cache: pass 'repo' to 'ce_mode_from_stat()' read-cache: remove redundant extern declarations
The 'excludes_file' and various other global configuration variables (including 'editor_program', 'pager_program', 'askpass_program', and 'push_default') have been migrated into the per-repository structure. * ty/migrate-excludes-file: repository: adjust the comment of config_values_private_ environment: move object_creation_mode into repo_config_values environment: move autorebase into repo_config_values environment: move push_default into repo_config_values environment: migrate apply_default_whitespace and apply_default_ignorewhitespace environment: move askpass_program into repo_config_values environment: move pager_program into repo_config_values environment: move editor_program into repo_config_values environment: move excludes_file into repo_config_values repository: introduce repo_config_values_clear()
Userdiff patterns for Swift have been added, with support for Swift-specific constructs such as attributes, modifiers, failable initializers, and generics. * sk/userdiff-swift: userdiff: add support for Swift
The 'git stash push' command has been optimized to avoid unnecessary sparse index expansion when pathspecs are wholly inside the sparse-checkout cone. Also, a potential out-of-bounds read in the sparse-index expansion check helper pathspec_needs_expanded_index() has been fixed by consistently using the parsed, prefixed path. * tn/stash-avoid-sparse-index-expansion: stash: avoid sparse-index expansion for in-cone paths pathspec: use match for sparse-index expansion checks
Configuration file locking has been updated to retry for a short period, avoiding failures when multiple processes attempt to update the configuration simultaneously. * jt/config-lock-timeout: config: retry acquiring config.lock, configurable via core.configLockTimeout
The 'remote-object-info' command has been added to 'git cat-file --batch-command', allowing clients to request object metadata (currently size) from a remote server via protocol v2 without downloading the entire object. Format placeholders are dynamically filtered on the client based on server-advertised capabilities, returning empty strings for inapplicable or unsupported fields. * ps/cat-file-remote-object-info: cat-file: make remote-object-info allow-list adapt to the server cat-file: add remote-object-info to batch-command transport: add client support for object-info serve: advertise object-info feature protocol-caps: check object existence regardless of the attributes requested fetch-pack: move fetch initialization connect: make write_fetch_command_and_capabilities() more generic fetch-pack: move write_fetch_command_and_capabilities() to connect.c fetch-pack: use unsigned int for hash_algo variable fetch-pack: drop the static advertise_sid variable t1006: extract helper functions into new 'lib-cat-file.sh' cat-file: declare loop counter inside for() transport-helper: fix memory leak of helper on disconnect
The object ID shortening and linking in the 'commitdiff' view of 'gitweb' has been corrected to work even when the index line carries a trailing file mode. * tl/gitweb-shorten-hashes-with-modes: gitweb: shorten index hashes with trailing file modes
The logic to write loose objects has been refactored and moved from 'object-file.c' to the loose backend source file 'odb/source-loose.c', making the loose backend more self-contained. This is achieved by first refactoring force_object_loose() to use generic ODB write interfaces instead of loose-backend internals. * ps/odb-move-loose-object-writing: object-file: move logic to write loose objects object-file: move `force_object_loose()` object-file: force objects loose via generic interface object-file: fix memory leak in `force_object_loose()` odb: support setting mtime when writing objects odb: lift object existence check out of the "loose" backend odb: compute object hash in `odb_write_object_ext()` t/u-odb-inmemory: implement wrapper for writing objects odb: compute compat object ID in `odb_write_object_ext()`
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The get_remote_group() function declaration continuation lines used mixed tabs and spaces for indentation, causing the check-whitespace CI job to fail with "indent with spaces" errors. Replace the mixed indentation with tabs only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.
For a single-commit pull request, please leave the pull request description
empty: your commit message itself should describe your changes.
Please read the "guidelines for contributing" linked above!