GeezerVison

When cURL follows a redirect, it calls the CURLOPT_HEADERFUNCTION for
each header received including ones from a redirect. http_request() sets
fwrite_wwwauth() as the header function, which will record the wwwauth[]
entries for the last step in the redirection chain.

However, when http_request_recoverable() sees that cURL followed a
redirect, it attempts to update the credentials for the request from the
new URL using credential_from_url(). The first thing that does is call
credential_clear(), which clears everything including wwwauth_headers.

If the new URL should use a credential helper rather than credentials
embedded in the URL, this loses the list of authentication methods that
the server provided in the redirect.

The WWW-Authenticate challenge is not derived from the URL; it is
populated from the server's response, and after a redirect it describes
how to authenticate to the redirect target and it needs to survive the
URL update so that credential helpers can know which authentication
methods are allowed.

Add a new credential_update_url() that wraps credential_from_url() and
preserves wwwauth_headers specifically. Use SWAP() to avoid having to
copy the whole strbuf.

Signed-off-by: Aaron Plattner <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The ability to provide a commit message for git commit --fixup and its
variations is limited:

  * Plain --fixup only allows using the -m flag

  * The amend/reword --fixup variants only allow supplying the message
    using an editor

For amend/reword, the -m and -F flags are rejected: -m is caught by a
die() in prepare_to_commit(), and -F is caught by
die_for_incompatible_opt4() which groups -F with --fixup as mutually
exclusive.  This makes these modes poorly suited for non-interactive
workflows -- notably when using AI coding agents.

When support to use the -m option was introduced in [1] it was noted
that there could be support for other options but at the time the use
case was deemed too niche.  Later, when the amend suboption was
introduced in [2] -m support for amend fixups was discussed but not
pursued, and -F was already caught by the higher-layer incompatibility
check grouping it with --fixup.

The rejections of these options hark back to when --fixup was
introduced in [3] and as noted in [1] -- there's nothing inherently
preventing support for them.  The current patchwork of which flags
work with which --fixup variants has no strong logic to it, and
allowing all of them simplifies both the code and the interface.

Allow -m and -F to supply the message body for all --fixup variations,
mirroring the flow of a regular commit.  -c and -C, which are blocked
by the same incompatibility check, are handled in the next commit.

1. 30884c9 (commit: add support for --fixup <commit> -m"<extra
   message>", 2017-12-22)

2. 494d314 (commit: add amend suboption to --fixup to create amend!
   commit, 2021-03-15)

3. d71b8ba (commit: --fixup option for use with rebase --autosquash,
   2010-11-02)

Helped-by: Junio C Hamano <[email protected]>
Suggested-by: Phillip Wood <[email protected]>
Signed-off-by: Erik Cervin-Edin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The fixup code path in prepare_to_commit() only knows how to take a
message body from -m or -F.  Now that the previous commit allows -m and
-F for all --fixup variations, -c/-C are the odd ones out.

Teach the fixup path to look up the ref given to -c/-C and seed its
message when preparing to amend the commit, mirroring what --fixup=amend
does when no message source is given.  With this in place, -m/-F/-c/-C
all behave consistently across the plain, amend, and reword --fixup
forms.

The incompatibility check grouping -C, -c, and --fixup can go away
entirely, as -C and -c are already rejected together by the check that
groups them with -m and -F.

Helped-by: Junio C Hamano <[email protected]>
Signed-off-by: Erik Cervin-Edin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

keyring_get() searches with SECRET_SEARCH_LOAD_SECRETS, then passes
secret_item_get_secret() of the first match unchecked to
secret_value_get_text() and secret_value_unref(). As libsecret
documents, that secret can be NULL: the search does not load secrets
of locked items, such as when SECRET_SEARCH_UNLOCK fails to unlock
them, and it ignores errors from loading secrets. The GNOME keyring
daemon also silently leaves out of its reply any item which is locked
or which was deleted after the search matched it, e.g. by a concurrent
"credential erase" from another git process. We then print

    secret_value_get_text: assertion 'value' failed
    secret_value_unref: assertion 'value != NULL' failed

before git falls back to prompting for the password.

We could keep the flag and load the secret explicitly only when it is
NULL, but SECRET_SEARCH_LOAD_SECRETS is not part of the search call:
libsecret implements it as a separate GetSecrets D-Bus call after
SearchItems. Drop the flag and instead always load the one secret we
use with secret_item_load_secret_sync(), which reports errors. This
takes as many D-Bus calls as before, and leaves a single code path
that runs every time, rather than a fallback that only runs in a rare
race. libsecret's own secret-tool also loads each secret explicitly
after searching.

An inaccessible item now produces a useful error message instead of
the assertion failures, and git still falls back to prompting. The
race needs a concurrent process or a locked keyring to trigger, so
there is no test.

Signed-off-by: Daniel Martí <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Scripts frequently need to find the root directory of a repository's
working tree. Currently, this requires using `git rev-parse --show-toplevel`
or inferring it from other repository information.

Introduce `path.toplevel.absolute` and `path.toplevel.relative` keys
to `git repo info`. This allows scripts to retrieve the top-level
working tree path in a predictable, strictly formatted manner without
relying on `rev-parse`.

If requested in a bare repository where no working tree exists, the
command returns an empty string.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

`get_superproject_working_tree()` currently uses `xgetcwd()` to
determine the repository whose superproject should be checked.

This is incorrect when `--git-dir` points to a repository different
from the one associated with the current working directory. In that
case, the current working directory may cause the function to return
the wrong superproject or an empty result.

Pass the `repository` to `get_superproject_working_tree()` so that the
superproject is determined from the repository being inspected rather
than the current working directory.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Scripts working in multi-repository setups often need to identify the
top-level working tree of a superproject from within a submodule.
Currently, this is only exposed via `git rev-parse
--show-superproject-working-tree`.

Introduce `path.superproject-root.absolute` and
`path.superproject-root.relative` keys to `git repo info`.
This exposes the core submodule context via a scriptable config-like key
using standard format rules.

If requested when not inside a submodule, the command returns an empty
string.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Hooks are an integral part of a repository's configuration and are
commonly used by tooling to automate repository-specific workflows.
Currently, scripts typically retrieve the hooks directory by invoking
`git rev-parse --git-path hooks`.

Introduce `path.hooks.absolute` and `path.hooks.relative` keys to
`git repo info`. This exposes the hooks directory as a scriptable
config-like key using standard format rules, allowing scripts to
retrieve it through the same interface as other repository path
information.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The repository index is a fundamental component used by Git and related
tooling to track the working tree state. Scripts that interact with the
index currently retrieve its location by invoking
`git rev-parse --git-path index`.

Introduce `path.index.absolute` and `path.index.relative` keys to
`git repo info`. This exposes the index file location as a scriptable
config-like key using standard format rules, allowing scripts to
retrieve it through the same interface as other repository path
information.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The repository grafts file specifies alternate parent relationships for
commits and may be used by repository tooling that needs to inspect or
manage grafts. Scripts currently retrieve its location by invoking
`git rev-parse --git-path info/grafts`.

Introduce `path.grafts.absolute` and `path.grafts.relative` keys to
`git repo info`. This exposes the grafts file location as a scriptable
config-like key using standard format rules, allowing scripts to
retrieve it through the same interface as other repository path
information.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Scripts sometimes need the path from the repository's working tree root
to the current working directory. While this information can be derived
through existing Git commands, `git repo info` does not currently expose
it as a scriptable key.

Introduce the `path.git-prefix` key to `git repo info`. The key returns
the path from the working tree root to the current working directory,
returning the empty string when invoked from the working tree root.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Scripts sometimes need the relative path from the current working
directory to the repository's working tree root (cdup). While this
information can be retrieved through `git rev-parse --show-cdup`,
`git repo info` does not currently expose it as a scriptable key.

Introduce the `path.cdup` key to `git repo info`. The key returns the
path from the current working directory to the root of the working tree,
returning the empty string when invoked from the working tree root.

Mentored-by: Justin Tobler <[email protected]>
Mentored-by: Lucas Seiki Oshiro <[email protected]>
Signed-off-by: K Jayatheerth <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

When the monitor sends a trivial response ("/"), for example after
the daemon restarted or lost events, refresh_fsmonitor() marks every
index entry dirty, which is saved in the index. For the untracked
cache it only clears the in-memory flag use_fsmonitor. The valid bits
of the cached directories are saved unchanged, although nothing
checks them anymore: valid_cached_dir() does not lstat() a valid
directory while the monitor is trusted.

A command that does not scan for untracked files, like "git add" or
"git checkout", therefore saves the new token next to stale valid
bits, and every later "git status" trusts them. A directory removed
in the meantime keeps its untracked files listed, or, when its own
entry is invalid, makes every run print
```
warning: could not open directory 'sub/': No such file or directory
```
Check every cached directory against its stat data before the cache
is saved next to such a token, as valid_cached_dir() does without a
monitor, and invalidate the ones that changed or disappeared. Doing
this at write time skips commands that do not write the index, and
sparse index writes, which drop the fsmonitor extension anyway.
The cost is one lstat() per cached directory, once per trivial
response.

Signed-off-by: Ilia K <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The `get_path_prefix()` function uses a `do ... while()` loop that
unconditionally decrements the `size_t` index variable before checking
the loop condition. When that variable is 0 on entry, the decrement
wraps to `SIZE_MAX`, and `path[SIZE_MAX]` is an out-of-bounds read.

The current caller (`write_tar_entry()`) only invokes this function when
`pathlen > sizeof(header.name)` i.e. when `pathlen` is at least 100.
Therefore, the bug is unreachable in practice.

However, the function's interface accepts arbitrary pathlen and maxlen
values, and a future caller or a maxlen of 0 could trigger the wrap, so
let's add a check for that.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The `fwrite_sha1_file()` function tracks the number of bytes written via
an `int` variable, but the total size to write is of type `size_t`. When
the HTTP response body exceeds INT_MAX (~2GB), this causes an overflow
and a heap under-read, then writes that data to the local object file.

The hash check afterward would reject the corrupt object (so no bad data
enters the object store), but the under-read itself could leak adjacent
heap contents to the temporary file. In practice this is unlikely
because curl delivers data in small chunks (typically 16KB per callback
invocation), so in practice, the total size is far below INT_MAX in a
single call. However, the function interface accepts arbitrary sizes,
and the accumulation across the loop means that the `int` variable grows
across calls within a single invocation, not across callbacks.

Change the type from `int` to `size_t` to match the type of the total
size. This is a hardening fix: the attack surface (a malicious HTTP
server triggering a >2GB single-callback delivery) is theoretical under
normal curl configurations, but the type mismatch is a genuine defect.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Both the `read_in_full()` as well as the `write_in_full()` function
accumulate the bytes transferred count in a variable of type `ssize_t`,
but accept a `size_t` count parameter. When count exceeds `SSIZE_MAX`,
that total count overflows after processing `SSIZE_MAX` bytes, producing
a negative return value that callers interpret as an error (or worse, a
small positive value after further wrapping).

In practice, git never passes such large counts because file sizes and
buffer allocations are bounded well below SSIZE_MAX on all target
platforms. The POSIX specification for `read()` and `write()` also
limits single operations to `SSIZE_MAX` bytes, and git's
`xread()`/`xwrite()` wrappers further clamp to `MAX_IO_SIZE`. But the
accumulation in the `*_in_full()` wrappers means that even with per-call
clamping, total can exceed `SSIZE_MAX` when count does.

Reject a total count that exceeds the range of `ssize_t` upfront with
`EINVAL` rather than silently producing wrong return values, matching
the POSIX convention for invalid arguments.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

`unsigned_mult_overflows()` does not cover signed arithmetic, but types
such as `time_t` can be signed or unsigned. Add signed and type-generic
guards so callers can check multiplication overflow in either case.

Overflow depends on the product type selected by C's usual arithmetic
conversions. Products equal to the signed minimum are representable and
must not be rejected.

Assisted-by: Claude Opus 4.6, GPT-6 and GPT-6.1
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The `approxidate_alpha()` function multiplies a time unit length (e.g.,
604800 for weeks) by a user-supplied number to compute a time offset in
seconds. Both operands are `int`, and the product is passed to
`update_tm()` as `time_t`. For inputs like "99999 weeks ago", the int
multiplication overflows (604800 * 99999 is roughly 60 billion, far
beyond `INT_MAX`), producing a wrapped value that results in a wrong
date.

Use the checked `time_t` multiplication so oversized products do not
overflow or wrap around.

On platforms where `time_t` is unsigned (and where the pre-processor
allows us to determine this fact), reject counts that are too large and
report a parse error. Narrowing them first could otherwise produce
negative or truncated values that become bogus offsets. Leave signed
`time_t` count parsing unchanged.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6 and GPT-6.1 Sol
Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The current explanation has the following issues:

- Says detached HEAD state is useful but doesn't explain why
- Takes many paragraphs before explaining what detached HEAD state is
- It's common for users to accidentally end up in detached HEAD state,
  but it doesn't explain why that might happen
- One of the UI improvements in `git switch` is to make it harder
  to detach accidentally, but that isn't advertised.
  See 7968bef (switch: only allow explicit detached HEAD, 2019-03-29)
- Too many confusing diagrams

Write a new explanation addressing these issues, and put it in a
standalone guide so that we can easily reference it from advice
("see `git help detached-head`").
The result is a shorter guide that covers more material.

The framing that "Git considers commits that aren't on a branch/other
reference to be garbage" is taken from Steve Klabnik's tutorial
https://steveklabnik.github.io/jujutsu-tutorial/branching-merging-and-conflicts/anonymous-branches.html.
It's funny and it's consistent with the way Git uses the term
"garbage collection".

Co-authored-by: Marie Claire LeBlanc Flanagan <[email protected]>
Signed-off-by: Marie Claire LeBlanc Flanagan <[email protected]>
Signed-off-by: Julia Evans <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The only "mktree --batch" test in t1010 is the one checking that it
survives a concurrent repack. Nothing covers basic batch mode, which
is how the leak fixed in 6272f3b (mktree: plug per-tree leak in
--batch mode, 2026-08-29) went unnoticed.

Add a few tests for it. Two trees in one batch should get the same
IDs as running plain "mktree" on each, a trailing blank line should
not add an extra tree, -z input should work, and a tree that names a
missing object should make mktree die after printing the trees before
it. While at it, check that a blank line is rejected without --batch.

One test feeds two blank lines in a row and expects an empty tree in
between. That is what mktree does today, but the documentation says
trees are separated by "a single blank line", so I am not sure it is
intended. The test records the current behaviour.

Suggested-by: Jeff King <[email protected]>
Signed-off-by: Roger Koranteng <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The `repo_rerere()` function is the only function in "rerere.h" that
does not have a `rerere_` prefix. And while it does indeed receive a
repository as first parameter, that's not a good-enough reason to give
it a `repo_` prefix.

Rename the function to just `rerere()`. Move around and extend
documentation of this function to better explain what it does.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

Our modern coding guidelines say that flags should typically be passed
around as enums so that it becomes trivial to see what kind of flags are
expected. Adapt the rerere flags accordingly and document them.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

There are a couple of references to `the_repository` in git-rerere(1).
As that command cannot run outside of a repository these references can
be trivially replaced by the repository that's passed in as parameter to
`cmd_rerere()`. We don't have to worry about the repository being `NULL`
when called with "-h", either, as there are no references to the repo
before we call `parse_options()`.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The git-rerere(1) command has a "--[no-]rerere-autoupdate" flag. If
passed, we explicitly enable or disable recording clean merge
resolutions that are staged in the index. This flag only matters to
git-rerere(1) when not executed with any subcommand, but we also forward
the flag to `git rerere status` and `git rerere diff`.

This is mostly harmless as we would ignore those flags anyway, but it
makes subsequent refactorings harder to understand. Prepare for these
refactorings by not using the flag in those subcommands anymore.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

The git-rerere(1) command has its own, home-grown implementation of
subcommands. Of course this implementation is inconsistent with how
subcommands typically work:

  - Options from other subcommands apply to each other.

  - We don't have proper usage strings.

  - Running `git rerere <subcmd> -h` doesn't print the options that are
    supported by that subcommand, but instead it just prints the help of
    git-rerere(1) itself.

A subsequent commit will thus introduce proper subcommands as supported
by our parse-options subsystem. Refactor the "forget" subcommand to use
parse-options as a preparatory step. The other commands will follow in
subsequent commits until all of them have been converted, and then we
switch over to `OPT_SUBCOMMAND()`.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

As explained in a preceding commit, a subsequent commit will introduce
proper subcommands as supported by our parse-options subsystem. Refactor
the "clear" subcommand to use parse-options as a preparatory step.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

As explained in a preceding commit, a subsequent commit will introduce
proper subcommands as supported by our parse-options subsystem. Refactor
the "status" subcommand to use parse-options as a preparatory step.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

As explained in a preceding commit, a subsequent commit will introduce
proper subcommands as supported by our parse-options subsystem. Refactor
the "remaining" subcommand to use parse-options as a preparatory step.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

As explained in a preceding commit, a subsequent commit will introduce
proper subcommands as supported by our parse-options subsystem. Refactor
the "diff" subcommand to use parse-options as a preparatory step.

Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>

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 'git repo info' command has been taught more keys to output
paths of various repository components (such as the working tree
root, superproject working tree, object database, etc.), supporting
both absolute and relative path formats.

* kj/repo-info-more-path-keys:
  repo: add path.cdup
  repo: add path.git-prefix
  repo: add path.grafts with absolute and relative suffixes
  repo: add path.index with absolute and relative suffixes
  repo: add path.hooks with absolute and relative suffixes
  repo: add path.superproject-root with absolute and relative suffixes
  submodule: use repository to find superproject
  repo: add path.toplevel with absolute and relative suffix formatting

The parser for hex object names has been updated to reject uppercase
hexadecimal characters when running in the breaking changes mode, in
preparation for Git 3.0.

* bc/restrict-hex-to-lowercase:
  hex: allow only lowercase object IDs in breaking changes mode
  t5324: adjust tests for corrupt commit-graph
  object-name: use hexval
  hex: label usages of hex parsing for object IDs
  hex: make hex_to_bytes accept kind of hex to use
  hex: allow specifying hex type with hex2chr
  hex: add functionality for lowercase-only hex

The default fetch negotiator has been updated to stop relying on the
global 'the_repository' variable and instead use the repository
context passed during its initialization.

* oa/negotiator-default-no-the-repository:
  negotiator/default: stop using the_repository

The forwarding of the '--force-with-lease' option when pushing to a
remote group has been fixed to ensure that both bare
'--force-with-lease' and '--force-with-lease=<ref>:' forms are
correctly passed to the underlying push commands.

* tc/push-multiple-force-with-lease:
  push: fix --force-with-lease forwarding in push_multiple()

The 'libsecret' credential helper has been updated to explicitly
load secrets instead of relying on the search flag, preventing
assertion failures when items are concurrently deleted or locked.

* dm/libsecret-explicit-load:
  credential/libsecret: load secrets explicitly

The manual page linter has been extended to ensure that concept
guides and interface manuals listed in the documentation makefile
are also properly featured in the command list.

* 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)

Use memset() to initialize repository configuration values to
zero, removing the need for explicit zero and NULL assignments.
Keep non-zero defaults initialized separately.

Signed-off-by: Joy Gundu <[email protected]>