summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-05-09mingw: drop the build-system plumbing for nedmallocJohannes Schindelin4-20/+0
With the previous commit removing every opt-in, the build-system plumbing for nedmalloc has nothing left to switch on. Remove it so that the upcoming deletion of the compat/nedmalloc/ tree is a pure file removal. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-09mingw: stop using nedmallocJohannes Schindelin3-6/+1
The vendored nedmalloc allocator under compat/nedmalloc/ has been unmaintained upstream for a very long time: the original repository at https://github.com/ned14/nedmalloc received its last commit on July 5, 2014, and was archived (made read-only) by its owner on March 15, 2019. Our copy has been carried forward unchanged ever since. The Git for Windows commit that introduced mimalloc as a replacement on Windows ("mingw: use mimalloc", 2019-06-24, present in the Git for Windows branch thicket but not upstream) already observed at that time that nedmalloc had ceased to see any updates for several years. This came to a head when the Git for Windows SDK upgraded to GCC 16: the `add_segment()` function in `compat/nedmalloc/malloc.c.h` declares `int nfences = 0` and only references it inside an `assert()`, which GCC 16 now flags as `-Wunused-but-set-variable`. Combined with the `-Werror` enabled by `DEVELOPER=1`, this turns into a hard build failure: compat/nedmalloc/malloc.c.h: In function 'add_segment': compat/nedmalloc/malloc.c.h:3897:7: error: variable 'nfences' set but not used [-Werror=unused-but-set-variable=] 3897 | int nfences = 0; | ^~~~~~~ cc1.exe: all warnings being treated as errors The same source built without complaint under GCC 15.2.0; the regression was bisected to the SDK package update at https://github.com/git-for-windows/git-sdk-64/commit/188d93dd455 (`mingw-w64-x86_64-gcc 15.2.0-14 -> 16.1.0-1`), with the failing CI run captured at https://github.com/git-for-windows/git-sdk-64/actions/runs/25244795074. Rather than patch the unmaintained vendored sources to silence the warning, stop opting into nedmalloc altogether on Windows. The platform allocator is what every non-MINGW build already uses, and a fresh build of git.git's master against a minimal Git for Windows SDK upgraded to GCC 16 completes successfully. The compat/nedmalloc/ subtree itself is removed by subsequent commits in this series. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-08doc: add caveat about turning off commit-graphKristoffer Haugsbakk2-0/+13
The doc `technical/commit-graph.adoc` says that replace objects and commit grafts turn off commit-graph: Commit grafts and replace objects can change the shape of the commit history. The latter can also be enabled/disabled on the fly using `--no-replace-objects`. This leads to difficulty storing both possible interpretations of a commit id, especially when computing generation numbers. The commit-graph will not be read or written when replace-objects or grafts are present. But this isn’t mentioned in the user-facing doc. Let’s mention it on git-replace(1) and git-commit-graph(1). Acked-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-08maintenance(geometric): do release the `.idx` files before repackingJohannes Schindelin2-1/+22
As is done for all the other maintenance tasks, let's release the ODB also before starting the geometric repacking. That way, the `.idx` files won't be `mmap()`ed when they are to be deleted (which does not work on Windows because you cannot delete files on that platform as long as they are kept open by a process). This regression was introduced by 9bc151850c1c (builtin/maintenance: introduce "geometric-repack" task, 2025-10-24), but was only noticed once geometric repacking was made the default in 452b12c2e0fe (builtin/ maintenance: use "geometric" strategy by default, 2026-02-24). The fix recapitulates my work from df76ee7b77f0 (run-command: offer to close the object store before running, 2021-09-09) & friends. To guard against future regressions of this kind, add a check to `run_and_verify_geometric_pack()` in `t7900` that detects orphaned `.idx` files left behind after repacking. Contrary to interactive calls, the `git maintenance` call in that test case would _not_ block on Windows, asking whether to retry deleting that file, which is the reason why this bug was not caught earlier. Furthermore, since the default behavior of `DeleteFileW()` was changed at some point between Windows 10 Build 17134.1304 and Build 18363.657 to use POSIX semantics (see https://stackoverflow.com/a/60512798), the added orphaned-`.idx` check would be insufficient to catch this regression on modern Windows without emulating legacy delete semantics via `GIT_TEST_LEGACY_DELETE=1`. This fixes https://github.com/git-for-windows/git/issues/6210. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-08mingw: optionally use legacy (non-POSIX) delete semanticsJohannes Schindelin1-2/+45
At some point between Windows 10 Build 17134.1304 and Build 18363.657, the default behavior of `DeleteFileW()` was changed to use POSIX semantics (https://stackoverflow.com/a/60512798). Under those semantics, a file can be deleted even when another process holds an active `MapViewOfFile` view on it: the directory entry is removed immediately, but the underlying data persists until the last handle is closed. On older Windows versions (and Windows 10 builds before that change), `DeleteFileW()` uses legacy semantics where deletion fails outright if any process holds a file mapping. To allow testing code paths that depend on the legacy behavior, introduce a `GIT_TEST_LEGACY_DELETE` environment variable. When set, `mingw_unlink()` uses `SetFileInformationByHandle()` with `FileDispositionInfo` (the non-POSIX variant) instead of `DeleteFileW()`, forcing legacy delete semantics regardless of the Windows version. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06t9904: add tests for the new url-parse builtinMatheus Afonso Martins Moreira2-0/+320
Test git URL parsing, validation and component extraction on all documented git URL schemes and syntaxes. Add IPv6 host coverage in URL form: ssh://[::1]/path ssh://user@[::1]:1234/path git://[::1]:9418/path http://[2001:db8::1]/path https://[2001:db8::1]/path In URL form the brackets are kept in the host component (RFC 3986 syntax for IPv6 literals). Also exercise the bracketed scp short forms that t5601-clone.sh covers via parse_connect_url: [host]:path [host:port]:path [::1]:repo user@[::1]:repo user@[host:port]:path In scp form, brackets are kept for IPv6 literals (two or more inner colons) and stripped for plain hostnames or host:port pairs. Suggested-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06doc: describe the url-parse builtinMatheus Afonso Martins Moreira2-0/+81
The new url-parse builtin validates git URLs and optionally extracts their components. Helped-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com> Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06builtin: create url-parse commandMatheus Afonso Martins Moreira7-0/+141
Git commands can accept a rather wide variety of URLs syntaxes. The range of accepted inputs might expand even more in the future. This makes the parsing of URL components difficult since standard URL parsers cannot be used. Extracting the components of a git URL would require implementing all the schemes that git itself supports, not to mention tracking its development continuously in case new URL schemes are added. The url-parse builtin command is designed to solve this problem by exposing git's native URL parsing facilities as a plumbing command. Other programs can then call upon git itself to parse the git URLs and extract their components. This should be quite useful for scripts. Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06urlmatch: define url_parse functionMatheus Afonso Martins Moreira3-0/+173
Define url_parse, a general parsing function that supports all Git URLs including scp style URLs such as hostname:~user/repo. It is adapted from the algorithm in connect.c's parse_connect_url and reuses the shared enum url_scheme and url_get_scheme function that previous commits made available in url.h. The new parser and the connect path agree on scheme classification. url_parse has the same interface as url_normalize and uses the same data structures. Both functions accept the same URL forms with one deliberate exception. Bare local paths such as "/abs/path", "./rel" or "repo" are accepted by parse_connect_url as URL_SCHEME_LOCAL, but rejected by url_parse because url_normalize requires a URL with a scheme://host form. A consumer that wants to handle both URLs and local paths needs to dispatch on url_is_local_not_ssh before calling url_parse, just as the connect path does internally. The duplication with parse_connect_url is intentional. The two functions have different contracts: - parse_connect_url Calls die() on an unknown scheme and returns NUL-terminated host/path strings for the connect path - url_parse Returns NULL on failure while populating out_info->err, and exposes components as offset/length pairs into the normalized URL buffer, matching url_normalize. Reconciling both is possible, but not in the scope of the current patch set. Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06url: return URL_SCHEME_UNKNOWN instead of dyingMatheus Afonso Martins Moreira3-5/+7
Enumerate a URL_SCHEME_UNKNOWN result with value 0. Have url_get_scheme() return it for unrecognized schemes instead of calling die() itself. Move the die() call to parse_connect_url() where url_get_scheme() is used. This lets url_get_scheme() be used from contexts that need to identify a URL's scheme without aborting the program. For example, a future plumbing command that validates URLs. No external behavior change. parse_connect_url() still dies with the same translated message for unrecognized schemes. Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06url: move scheme detection to URL header/sourceMatheus Afonso Martins Moreira3-22/+29
Move enum url_scheme and url_get_scheme() from connect.c to url.h and url.c so that other code can identify a URL's scheme without depending on connect.c. No behavior change. url_get_scheme() still dies on an unrecognized scheme name, with the same translated message as before. scheme_name() stays in connect.c because it has no other callers. Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06url: move url_is_local_not_ssh to url.hMatheus Afonso Martins Moreira5-9/+11
Move url_is_local_not_ssh from connect.c/connect.h to url.c/url.h so that the new url_parse function in urlmatch.c, and any future code that needs to distinguish a local path from an scp style SSH URL, can reuse the heuristic without depending on connect.c. No behavior change. Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06connect: rename enum protocol to url_schemeMatheus Afonso Martins Moreira1-34/+34
RFC 1738 names the part of a URL before the colon a "scheme". connect.c calls it "protocol", which is more generic and collides with the unrelated enum protocol_version. Rename: enum protocol -> enum url_scheme PROTO_* -> URL_SCHEME_* prot_name -> url_scheme_name get_protocol -> url_get_scheme The local variables in parse_connect_url and git_connect are renamed accordingly, from protocol to scheme. No behavior change. The user-visible diagnostics and translated error messages are preserved: "Diag: protocol=..." "protocol '%s' is not supported" "unknown protocol" This rename also prepares for moving the scheme-detection functions to a shared header so that a future plumbing command can parse URLs using the same logic as the connect path. Suggested-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Matheus Afonso Martins Moreira <matheus@matheusmoreira.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06doc: restore: remove double underscoreKristoffer Haugsbakk1-1/+1
69666e67 (doc: convert git-restore to new style format, 2025-01-10) converted `A` to _<rev-A>__; the extra underscore was a mistake. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-06http: reject unsupported proxy URL schemesAliwoto2-25/+74
An explicit proxy URL with an unrecognized scheme such as htpp://127.0.0.1 is currently accepted. Git parses the URL, extracts the host part, and then passes only that host to libcurl. Because no proxy type is selected for the unknown scheme, Git leaves libcurl at its default HTTP proxy type, so the typo is silently treated as an HTTP proxy. Reject proxy URLs with explicit unsupported schemes instead of silently accepting them. Keep the existing host:port-without-scheme behavior unchanged. Implement the SOCKS proxy handling with a shared table-driven mapping. Add a regression test to cover the unsupported-scheme case. Signed-off-by: Aliwoto <aminnimaj@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05Merge branch 'en/backfill-fixes-and-edges' into ds/path-walk-filtersJunio C Hamano3-10/+153
* en/backfill-fixes-and-edges: backfill: default to grabbing edge blobs too backfill: document acceptance of revision-range in more standard manner backfill: reject rev-list arguments that do not make sense
2026-05-05refs: use peeled tag values in reference backendsKarthik Nayak2-11/+4
The reference backends peel tag objects when storing references to them. This is to provide optimized reads which avoids hitting the odb. The previous commits ensures that the peeled value is now propagated via the generic layer. So modify the packed and reftable backend to directly use this value instead of calling `peel_object()` independently. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: add peeled object ID to the `ref_update` structKarthik Nayak4-13/+42
Certain reference backends {packed, reftable}, have the ability to also store the peeled object ID for a reference pointing to a tag object. This has the added benefit that during retrieval of such references, we also obtain the peeled object ID without having to use the ODB. To provide this functionality, each backend independently calls the ODB to obtain the peeled OID. To move this functionality to the generic layer, there must be support infrastructure to pass in a peeled OID for reference updates. Add a `peeled` field to the `ref_update` structure and modify `ref_transaction_add_update()` to receive and copy this object ID to the `ref_update` structure. Finally, modify `ref_transaction_update()` to peel tag objects and pass the peeled OID to `ref_transaction_add_update()`. Update all callers of these functions with the new function parameters. Callers which only add reflog updates, need to only pass in NULL, since for reflogs, we don't store peeled OIDs. Reference deletions also only need to pass in NULL. For others, pass along the peeled OID if available. In a following commit, we'll modify the backends to use this peeled OID instead of parsing it themselves. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: move object parsing to the generic layerKarthik Nayak5-54/+47
Regular reference updates made via reference transactions validate that the provided object ID exists in the object database, which is done by calling 'parse_object()'. This check is done independently by the backends which leads to duplicated logic. Let's move this to the generic layer, ensuring the backends only have to care about reference storage and not about validation of the object IDs. With this also remove the 'REF_TRANSACTION_ERROR_INVALID_NEW_VALUE' error type as its no longer used. Since we don't iterate over individual references in `ref_transaction_prepare()`, we add this check to `ref_transaction_update()`. This means that the validation is done as soon as an update is queued, without needing to prepare the transaction. It can be argued that this is more ideal, since this validation has no dependency on the reference transaction being prepared. It must be noted that the change in behavior means that this error cannot be ignored even with usage of batched updates, since this happens when the update is being added to the transaction. But since the caller gets specific error codes, they can either abort the transaction or continue adding other updates to the transaction. Modify 'builtin/receive-pack.c' to now capture the error type so that the error propagated to the client stays the same. Also remove two of the tests which validates batch-updates with invalid new_oid. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05update-ref: handle rejections while adding updatesKarthik Nayak1-39/+98
When using git-update-ref(1) with the '--batch-updates' flag, updates rejected by the reference backend are displayed to the user while other updates are applied. This only applies during the commit phase of the transaction. In the following commits, we'll also extend `ref_transaction_update()` to reject updates before a transaction is prepared/committed. In preparation, modify the code in update-ref to also handle non-generic rejections from `ref_transaction_update()`. This involves propagating information to each of the commands on whether updates are allowed to be rejected, and also checking for rejections and only dying for generic failures. Errors encountered during updates will be shown to the user immediately unlike other errors encountered only when the transaction is prepared/committed. As the verification of object IDs and peeled tag objects will move into `ref_transaction_update()` in the following commit, this means that those errors will be shown to the user before other errors, this changes the order of errors, but the functionality remains the same. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05update-ref: move `print_rejected_refs()` upKarthik Nayak1-23/+22
The `print_rejected_refs()` function is used to print any rejected refs when using git-updated-ref(1) with the '--batch-updates' option. In the following commit, we'll need to use this function in another place, so move the function up to avoid a separate forward declaration. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: return `ref_transaction_error` from `ref_transaction_update()`Karthik Nayak2-18/+18
The `ref_transaction_update()` function is used to add updates to a given reference transactions. In the following commit, we'll add more validation to this function. As such, it would be beneficial if the function returns specific error types, so callers can differentiate between different errors. To facilitate this, return `enum ref_transaction_error` from the function and covert the existing '-1' returns to 'REF_TRANSACTION_ERROR_GENERIC'. Since this retains the existing behavior, no changes are made to any of the callers but this sets the necessary infrastructure for introduction of other errors. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: extract out reflog config to generic layerKarthik Nayak4-2/+9
The reference backends need to know when to create reflog entries, this is dictated by the 'core.logallrefupdates' config. Instead of relying on the backends to call `repo_settings_get_log_all_ref_updates()` to obtain this config value, let's do this in the generic layer and pass down the value to the backends. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: introduce `ref_store_init_options`Karthik Nayak6-10/+26
Reference backends are initiated via the `init()` function. When initiating the function, the backend is also provided flags which denote the access levels of the initiator. Create a new structure `ref_store_init_options` to house such options and move the access flags to this structure. This allows easier extension of providing further options to the backends. In the following commit, we'll also provide config around reflog creation to the backends via the same structure. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05refs: remove unused typedef 'ref_transaction_commit_fn'Karthik Nayak1-4/+0
The typedef 'ref_transaction_commit_fn' is not used anywhere in our code, let's remove it. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05xdiff: reduce the size of arrayPhillip Wood1-7/+4
When the myers algorithm is selected the input files are pre-processed to remove any common prefix and suffix and any lines that appear in only one file. This requires a map to be created between the lines that are processed by the myers algorithm and the lines in the original file. That map does not include the common lines at the beginning and end of the files but the array is allocated to be the size of the whole file. Move the allocation into xdl_cleanup_records() where the map is populated and we know how big it needs to be. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05xprepare: simplify error handlingPhillip Wood1-5/+2
If either of the two allocations fail we want to take the same action so use a single if statement. This saves a few lines and makes it easier for the next commit to add a couple more allocations. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05xdiff: cleanup xdl_clean_mmatch()Phillip Wood1-3/+4
Remove the "s" parameter as, since the last commit, this function is always called with s == 0. Also change parameter "e" to expect a length, rather than the index of the last line to simplify the caller. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05xdiff: reduce size of action arraysPhillip Wood1-14/+17
When the myers algorithm is selected the input files are pre-processed to remove any common prefix and suffix. Then any lines that appear only in one side of the diff are marked as changed and frequently occurring lines are marked as changed if they are adjacent to a changed line. This step requires a couple of temporary arrays. As as the common prefix and suffix have already been removed, the arrays only need to be big enough to hold the lines between them, not the whole file. Reduce the size of the arrays and adjust the loops that use them accordingly while taking care to keep indexing the arrays in xdfile_t with absolute line numbers. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-05Merge branch 'en/xdiff-cleanup-3' into pw/xdiff-shrink-memory-consumptionJunio C Hamano4-32/+73
* en/xdiff-cleanup-3: xdiff/xdl_cleanup_records: make execution of action easier to follow xdiff/xdl_cleanup_records: make setting action easier to follow xdiff/xdl_cleanup_records: make limits more clear xdiff/xdl_cleanup_records: use unambiguous types xdiff: use unambiguous types in xdl_bogo_sqrt() xdiff/xdl_cleanup_records: delete local recs pointer
2026-05-04push: support pushing to a remote groupUsman Akinyemi4-41/+451
`git fetch` accepts a remote group name (configured via `remotes.<name>` in config) and fetches from each member remote. `git push` has no equivalent — it only accepts a single remote name. Teach `git push` to resolve its repository argument through `add_remote_or_group()`, which was made public in the previous patch, so that a user can push to all remotes in a group with: git push <group> When the argument resolves to a single remote, the behaviour is identical to before. When it resolves to a group, each member remote is pushed in sequence. The group push path rebuilds the refspec list (`rs`) from scratch for each member remote so that per-remote push mappings configured via `remote.<name>.push` are resolved correctly against each specific remote. Without this, refspec entries would accumulate across iterations and each subsequent remote would receive a growing list of duplicated entries. Mirror detection (`remote->mirror`) is also evaluated per remote using a copy of the flags, so that a mirror remote in the group cannot set TRANSPORT_PUSH_FORCE on subsequent non-mirror remotes in the same group. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-04remote: move remote group resolution to remote.cUsman Akinyemi3-42/+49
`get_remote_group`, `add_remote_or_group`, and the `remote_group_data` struct are currently defined as static helpers inside builtin/fetch.c. They implement generic remote group resolution that is not specific to fetch — they parse `remotes.<name>` config entries and resolve a name to either a list of group members or a single configured remote. Move them to remote.c and declare them in remote.h so that other builtins can use the same logic without duplication. Useful for the next patch. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-04remote: fix sign-compare warnings in push_cas_optionUsman Akinyemi1-2/+2
Replace `int` with `size_t` for `nr` and `alloc` in `struct push_cas_option` to avoid -Werror=sign-compare warnings when comparing against size-based values. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-02worktree: rename get_worktree_from_repository()Phillip Wood3-3/+3
get_worktree_from_repository() returns a struct worktree that describes the worktree that the repository argument would operate on. Since 0f779147602 (worktree: remove "the_repository" from is_current_worktree(), 2026-03-26) that worktree is always the "current" worktree. Change the name to get_current_worktee() to reflect better what the function does. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-05-01doc: clarify http.emptyAuth valuesMatthew John Cheetham1-1/+12
The existing description of http.emptyAuth explains the purpose of the setting but never says what values it accepts. Readers have to infer from context (or read the source) that it takes 'true', 'false', or 'auto', and what each one means. Document the three accepted values explicitly: * 'auto' (the default) only sends empty credentials when the server's 401 response advertises a mechanism that requires them, such as GSS-Negotiate. This matches the long-standing auto-detection behaviour added in 40a18fc77c (http: add an "auto" mode for http.emptyauth, 2017-02-25). * 'true' unconditionally sends empty credentials on the very first request, before any 401 response, for callers that know they want this behaviour up front. * 'false' disables the feature entirely; mechanisms that depend on empty credentials, such as GSS-Negotiate, will not work in this mode. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30l10n: bump mshick/add-pr-comment from v2 to v3Johannes Schindelin1-1/+1
The l10n workflow uses `mshick/add-pr-comment` to post git-po-helper reports as comments on translation pull requests. It was still pinned to v2, which runs on Node.js 20. GitHub is phasing out the Node.js 20 runtime on Actions runners, so staying on v2 will eventually cause the "Create comment in pull request for report" step to fail. The sole breaking change in v3 is the switch from Node.js 20 to Node.js 24 (https://github.com/mshick/add-pr-comment/releases/tag/v3.0.0). The action's inputs and outputs are unchanged, so the upgrade is a drop-in replacement. Subsequent v3.x releases added new opt-in features (message truncation, retry with exponential backoff, file attachments, commit comment support, "delete on status") but none of them affect existing callers that do not opt in. See also: - Changelog: https://github.com/mshick/add-pr-comment/blob/main/CHANGELOG.md - Compare: https://github.com/mshick/add-pr-comment/compare/v2...v3 Pointed-out-by: Christoph Grüninger <foss@grueninger.de> Assisted-by: Claude Opus 4.6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30ci: bump git-for-windows/setup-git-for-windows-sdk from v1 to v2Johannes Schindelin2-5/+5
The v1 of `git-for-windows/setup-git-for-windows-sdk` runs on Node.js 20, which GitHub is phasing out of the Actions runners. v2 moves the action to Node.js 24 so that the CI jobs relying on a Git for Windows SDK keep working once Node.js 20 is removed. The risk is very low: v2 contains no functional changes to the SDK setup itself, only the runtime upgrade. The action still provisions the same minimal SDK and exposes the same outputs. The sole precondition is a recent Actions Runner (>= 2.327.1), which the github.com-hosted runners already satisfy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30ci: bump actions/checkout from v5 to v6Johannes Schindelin4-15/+15
Every workflow currently pins `actions/checkout` to v5, which was introduced primarily to move to the Node.js 24 runtime. v6 is the next release and worth picking up so we stay on a maintained version of the action. The one behaviorally interesting change in v6: `persist-credentials` now stores the helper credentials under `$RUNNER_TEMP` instead of writing them directly into the local `.git/config`. Two implications follow: 1. In the normal case this is an unambiguous improvement -- the token no longer lands in `.git/config`, reducing the risk of inadvertently leaking it through workspace archiving (`upload-artifact` snapshots, cache entries, core dumps, ...). 2. Docker container actions require an Actions Runner of at least v2.329.0 to find the credentials in their new location. The github.com-hosted runners our CI uses are already past that version, so this does not affect us. Downstream users running self-hosted runners may need to update them before adopting this version of the action. Risk analysis: our checkout steps either check out the default repository (no special credential requirements) or, in the `vs-build` job, explicitly set `repository: microsoft/vcpkg` and `path: compat/vcbuild/vcpkg`. Neither case relies on the precise location of the persisted credentials -- subsequent steps interact with the API via the runner-provided `GITHUB_TOKEN` directly -- so the v6 credential-storage change is transparent to our workflows. The diff is purely the `@vN` identifier; there are no input or output changes. See also: - Release notes: https://github.com/actions/checkout/releases - Changelog: https://github.com/actions/checkout/blob/main/CHANGELOG.md - Compare: https://github.com/actions/checkout/compare/v5...v6 Originally-authored-by: dependabot[bot] <support@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30ci: bump actions/github-script from v8 to v9Johannes Schindelin1-1/+1
The only use we have of `actions/github-script` is the "skip if the commit or tree was already tested" step in `main.yml`, which checks whether an identical tree-SHA was already built successfully. It currently pins v8; v9 is the latest release. What v9 changes: - The `ACTIONS_ORCHESTRATION_ID` environment variable is now appended to the HTTP user-agent string. This is transparent to our script. - A new injected `getOctokit` factory lets scripts create additional authenticated clients in the same step without importing `@actions/github`. We do not use it. - Two breaking changes affect scripts that either call `require('@actions/github')` (fails at runtime, because `@actions/github` v9 is now ESM-only) or that shadow the implicit `getOctokit` parameter via `const`/`let` (syntax error). Our script does neither -- it only uses the pre-supplied `github` REST client and `core` helpers -- so the upgrade is safe. Risk analysis: the step is advisory. It sets `enabled=' but skip'` as an optimization to avoid re-running CI on a tree that was already tested successfully. Even if the v9 upgrade broke the script, the surrounding `try { ... } catch (e) { core.warning(e); }` block would degrade it to a warning and CI would still run normally. In practice the script continues to work identically on v9. See also: - Release notes: https://github.com/actions/github-script/releases - Compare: https://github.com/actions/github-script/compare/v8...v9 Originally-authored-by: dependabot[bot] <support@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30ci: bump actions/{upload,download}-artifact to v7 and v8Johannes Schindelin1-11/+11
`actions/upload-artifact` and `actions/download-artifact` are tightly coupled: the upload action writes artifact archives in a format that the download action then reads. Because of this coupling, the two actions should always be bumped together so that the artifact format contract between them is satisfied. All of our `actions/upload-artifact` uses are still on v5, with one stray v4 occurrence. Keeping them on these versions would leave the artifact-upload steps running on Node.js 20, which GitHub is phasing out, and would eventually cause all upload steps to fail. Going from v5 directly to v7 folds in two release bumps: - v6 switches the action's default runtime from Node.js 20 to Node.js 24 (v5 had preliminary Node 24 support but still defaulted to Node 20). This is the main motivation for bumping now: it gets us off the deprecated runtime. - v7 adds two opt-in features: direct (unzipped) single-file uploads via a new `archive: false` parameter, and an internal conversion of the action to ESM to match the updated `@actions/*` packages. Risk analysis: we never pass `archive`, so the zip-as-usual behavior is unchanged. We also do not `require('@actions/*')` from any calling workflow, so the ESM migration cannot affect us. The upload steps we care about -- tracked files/build artifacts and failing-test directories -- keep the same inputs (`name`, `path`) and outputs, so the diff is purely the `@vN` identifier. The main precondition is a recent Actions Runner (>= 2.327.1), which the github.com-hosted runners used by our CI already satisfy. While at it, align the one remaining `@v4` occurrence with the rest so that every `upload-artifact` step uses the same version. See also: - Release notes: https://github.com/actions/upload-artifact/releases - Compare: https://github.com/actions/upload-artifact/compare/v5...v7 We use `actions/download-artifact` to pass build artifacts between the "windows-build" / "vs-build" / "windows-meson-build" jobs and their corresponding test jobs. All callers are currently on v6; bumping to v8 keeps this action in lockstep with the `upload-artifact` bump above. What v7 and v8 change: - v7 switches the default runtime from Node.js 20 to Node.js 24 (v6 had preliminary Node 24 support but still defaulted to Node 20). This is the main motivation: it gets us off the deprecated runtime. - v8 makes three further changes: * The package is converted to ESM (invisible to workflow authors). * The action now checks the `Content-Type` header before attempting to unzip a download, so that directly-uploaded (unzipped) artifacts from `upload-artifact` v7 are downloaded correctly. * The `digest-mismatch` behaviour is changed from warn-and- continue to a hard failure by default. Risk analysis: defaulting hash-mismatch to a hard failure is strictly safer than the previous warn-and-continue behaviour -- a mismatch points to real corruption or tampering and should stop the run. We download archives that the same workflow just uploaded, on the same runner fleet, so false positives are not expected. Our usage is limited to the `name` and `path` inputs, which are unchanged between v6 and v8, so the diff is purely the `@vN` identifier. See also: - Release notes: https://github.com/actions/download-artifact/releases - Compare: https://github.com/actions/download-artifact/compare/v6...v8 Originally-authored-by: dependabot[bot] <support@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30ci: bump microsoft/setup-msbuild from v2 to v3Johannes Schindelin1-1/+1
The v2 of `microsoft/setup-msbuild` runs on Node.js 20, which GitHub is phasing out of the Actions runners. v3 is a minimal release whose only substantive change is moving the action's runtime to Node.js 24, so that our Visual Studio build jobs keep working once Node.js 20 is removed from the runners. The risk of this bump is very low: v3 contains no functional changes to the action itself -- it merely adds `msbuild.exe` to `PATH`, with no change to command-line flags, inputs, outputs, or default tool resolution. The only precondition is a recent-enough Actions Runner, which the github.com-hosted runners already satisfy. See also: - Release notes: https://github.com/microsoft/setup-msbuild/releases - Compare: https://github.com/microsoft/setup-msbuild/compare/v2...v3 Originally-authored-by: dependabot[bot] <support@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff/xdl_cleanup_records: make execution of action easier to followEzekiel Newren1-10/+30
Helped-by: Phillip Wood Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff/xdl_cleanup_records: make setting action easier to followEzekiel Newren1-2/+12
Rewrite nested ternaries with a clear if/else ladder for action1/action2 to improve readability while preserving behavior. Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff/xdl_cleanup_records: make limits more clearEzekiel Newren1-7/+19
Make the handling of per-file limits and the minimal-case clearer. * Use explicit per-file limit variables (mlim1, mlim2) and initialize them. * The additional condition `!need_min` is redudant now, remove it. Best viewed with --color-words. Helped-by: Phillip Wood Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff/xdl_cleanup_records: use unambiguous typesEzekiel Newren1-3/+3
Change the parameters of xdl_clean_mmatch() and the local variables i, nm, mlim in xdl_cleanup_records() to use unambiguous types. Best viewed with --color-words. Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff: use unambiguous types in xdl_bogo_sqrt()Ezekiel Newren4-6/+6
There is no real square root for a negative number and size_t may not be large enough for certain applications, replace long with uint64_t. Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-30xdiff/xdl_cleanup_records: delete local recs pointerEzekiel Newren1-9/+8
Simplify the first 2 for loops by directly indexing the xdfile.recs. recs is unused in the last 2 for loops, remove it. Best viewed with --color-words. Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-29checkout -m: autostash when switching branchesHarald Nordgren9-150/+219
When switching branches with "git checkout -m", the attempted merge of local modifications may cause conflicts with the changes made on the other branch, which the user may not want to (or may not be able to) resolve right now. Because there is no easy way to recover from this situation, we discouraged users from using "checkout -m" unless they are certain their changes are trivial and within their ability to resolve conflicts. Teach the -m flow to create a temporary stash before switching and reapply it after. On success, the stash is silently applied and the list of locally modified paths is shown, same as a successful "git checkout" without "-m". If reapplying causes conflicts, the stash is kept and the user is told they can resolve and run "git stash drop", or run "git reset --hard" and later "git stash pop" to recover their changes. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-29checkout: rollback lock on early returns in merge_working_treeHarald Nordgren1-7/+22
merge_working_tree() acquires the index lock via repo_hold_locked_index() but several early return paths exit without calling rollback_lock_file(), leaving the lock held. While this is currently harmless because the process exits soon after, it becomes a problem if the function is ever called more than once in the same process. Add rollback_lock_file() calls to all early return paths. Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-29sequencer: teach autostash apply to take optional conflict marker labelsHarald Nordgren4-14/+40
Add label_ours, label_theirs, label_base, and stash_msg parameters to apply_autostash_ref() and the autostash apply machinery so callers can pass custom conflict marker labels through to "git stash apply --label-ours/--label-theirs/--label-base", as well as a custom stash message for "git stash store -m". Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>