color: use git_colorbool enum type to store colorbools

We traditionally used "int" to store and pass around the values defined
by "enum git_colorbool" (which were originally just #define macros).
Using an int doesn't produce incorrect results, but using the actual
enum makes the intent of the code more clear.

It would be nice if the compiler could catch cases where we used the
enum and an int interchangeably, since it's very easy to accidentally
check the boolean true/false of a colorbool like:

  if (branch_use_color)

This is wrong because GIT_COLOR_UNKNOWN and GIT_COLOR_AUTO evaluate to
true in C, even though we may ultimately decide not to use color. But C
is pretty happy to convert between ints and enums (even with various
-Wenum-* warnings). So this sadly doesn't protect us from such mistakes,
but it hopefully does make the code easier to read.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pretty: use format_commit_context.auto_color as colorbool

When we see "%C(auto)" as a format placeholder, we evaluate the "color"
field of our pretty_print_context to decide whether we want color. The
auto_color field of format_commit_context then stores the boolean result
of want_color(), telling us the yes/no of whether we want color.

But the resulting field is passed to various functions which expect a
git_colorbool, like diff_get_color(), that will then pass it to
want_color() again. It's not wrong to do so, since want_color() is
idempotent. But it makes it harder to reason about the types, since we
sometimes confuse colorbools and strict booleans.

Let's instead store auto_color as the original colorbool itself. We'll
have to make sure it is passed through want_color() when it is
evaluated, but there is only one such spot (right next to where we
assign it!). Every other caller just ends up passing it to get
diff_get_color() either directly or through another helper.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: stop passing ecbdata->use_color as boolean

In emit_hunk_header(), we evaluate ecbdata->color_diff both as a
git_colorbool, passing it to diff_get_color():

  const char *reset = diff_get_color(ecbdata->color_diff, DIFF_RESET);

and as a strict boolean:

  const char *reverse = ecbdata->color_diff ? GIT_COLOR_REVERSE : "";

At first glance this seems wrong. Usually we store the color decision as
a git_colorbool, so the second line would get confused by GIT_COLOR_AUTO
(which is boolean true, but may still mean we do not produce color).

However, the second line is correct because our caller sets color_diff
using want_color(), which collapses the colorbool to a strict true/false
boolean. The first line is _also_ correct because of the idempotence of
want_color(). Even though diff_get_color() will pass our true/false
value through want_color() again, the result will be left untouched.

But let's pass through the colorbool itself, which makes it more
consistent with the rest of the diff code. We'll need to then call
want_color() whenever we treat it as a boolean, but there is only such
spot (the one quoted above).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: pass o->use_color directly to fill_metainfo()

We pass the use_color parameter of fill_metainfo() as a strict boolean,
using:

  want_color(o->use_color) && !pgm

to derive its value. But then inside the function, we pass it to
diff_get_color(), which expects one of the git_colorbool enum values,
and so feeds it to want_color() again.

Even though want_color() produces a strict 0/1 boolean, this doesn't
produce wrong results because want_color() is idempotent. Since
GIT_COLOR_ALWAYS and NEVER are defined as 1 and 0, and because
want_color() passes through those values, evaluating "want_color(foo)"
and "want_color(want_color(foo))" will return the same result.

But as part of a longer strategy to align the types we use for storing
these values, let's pass through the colorbool directly. To handle the
"&&" case here, we'll convert the presence of "pgm" into "NEVER", which
arguably makes the intent of the code more clear anyway.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: don't use diff_options.use_color as a strict bool

We disable --color-moved if color is not in use at all. This happens in
diff_setup_done(), where we set options->color_moved to 0 if
options->use_color is not true. But a strict boolean check here is not
correct; use_color could be GIT_COLOR_UNKNOWN or GIT_COLOR_AUTO, both of
which evaluate to true, even though we may later decide not to show
colors.

We should be using want_color() to convert that git_colorbool into a
true boolean. As it turns out, this does not produce wrong output. Even
though we go to the trouble to detect the moved lines, ultimately we get
the color values from diff_get_color(), which does check want_color().
And so it returns the empty string for each color, and we "color" the
result with nothing.

So the output is correct, but there is a small but measurable
performance cost to doing the line detection. E.g., in git.git before
and after this patch (there are no colors shown because hyperfine
redirects output to /dev/null):

  Benchmark 1: ./git.old log --no-merges -p --color-moved -1000
    Time (mean ± σ):      1.019 s ±  0.013 s    [User: 0.955 s, System: 0.064 s]
    Range (min … max):    1.005 s …  1.045 s    10 runs

  Benchmark 2: ./git.new log --no-merges -p --color-moved -1000
    Time (mean ± σ):     982.9 ms ±  14.5 ms    [User: 925.8 ms, System: 57.1 ms]
    Range (min … max):   965.1 ms … 1003.2 ms    10 runs

  Summary
    ./git.new log --no-merges -p --color-moved -1000 ran
      1.04 ± 0.02 times faster than ./git.old log --no-merges -p --color-moved -1000

Note that the fix is not quite as simple as just calling want_color()
from diff_setup_done(). There's a subtle timing issue that goes back to
daa0c3d971 (color: delay auto-color decision until point of use,
2011-08-17), the commit that adds want_color() in the first place.  As
discussed there, we must delay evaluating the colorbool value until all
pager setup is complete.

So instead, we'll leave the "color_moved" field intact in diff_setup_done(),
and modify the point where it is evaluated. Fortunately there is only
one such spot that controls whether we run any of the color-moved code
at all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: simplify color_moved check when flushing

In diff_flush_patch_all_file_pairs(), we set o->emitted_symbols if and
only if o->color_moved is true. That causes the lower-level routines to
fill up o->emitted_symbols, which we then analyze in order to do the
actual colorizing.

But in that final step, we do:

  if (o->emitted_symbols) {
          if (o->color_moved) {
     ...actual coloring...
  }
  ...clean up of emitted_symbols...
  }

The inner "if" will always trigger, since we set emitted_symbols only
when doing color_moved (it is a little confusing that it is set inside
the diff_options struct, but that is for convenience of passing it to
the lower-level routines; we always clear it at the end of flushing,
since 48edf3a02a (diff: clear emitted_symbols flag after use,
2019-01-24)).

Let's simplify the code a bit by just dropping the inner "if" and
running its block unconditionally.

In theory the current code might be useful if another feature besides
color_moved setup and used emitted_symbols, but it would be easy to
refactor later to handle that. And in the meantime, this makes further
work in this area easier.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep: don't treat grep_opt.color as a strict bool

In show_line(), we check to see if colors are desired with just:

  if (opt->color)
     ...we want colors...

But this is incorrect. The color field here is really a git_colorbool,
so it may be "true" for GIT_COLOR_UNKNOWN or GIT_COLOR_AUTO. Either of
those _might_ end up true eventually (once we apply default fallbacks
and check stdout's tty), but they may not. E.g.:

  git grep foo | cat

will enter the conditional even though we're not going to show colors.
We should collapse it into a true boolean by calling want_color().

It turns out that this does not produce a user-visible bug. We do some
extra processing to isolate the matched portion of the line in order to
colorize it, but ultimately we pass it to our output_color() helper,
which does correctly check want_color(). So we end up with no colors.

But dropping the extra processing saves a measurable amount of time. For
example, running under hyperfine (which redirects to /dev/null, and thus
does not colorize):

  Benchmark 1: ./git.old grep a
    Time (mean ± σ):      58.7 ms ±   3.5 ms    [User: 580.6 ms, System: 74.3 ms]
    Range (min … max):    53.5 ms …  67.1 ms    48 runs

  Benchmark 2: ./git.new grep a
    Time (mean ± σ):      35.5 ms ±   0.9 ms    [User: 276.8 ms, System: 73.8 ms]
    Range (min … max):    34.3 ms …  39.3 ms    79 runs

  Summary
    ./git.new grep a ran
      1.65 ± 0.11 times faster than ./git.old grep a

That's a fairly extreme benchmark, just because it will come up with a
ton of small matches, but it shows that this really does matter.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

color: return enum from git_config_colorbool()

The git_config_colorbool() function returns an integer which is always
one of the GIT_COLOR_* constants UNKNOWN, NEVER, ALWAYS, or AUTO. We
define these constants with macros, but let's switch to using an enum.
Even though the compiler does not strictly enforce enum/int conversions,
this should make the intent clearer to human readers. And as a bonus,
enum names are typically available to debuggers, making it more pleasant
to step through the code there.

This patch updates the return type of git_config_colorbool(), but holds
off on updating all of the callers. There's some trickiness to some of
them, and in the meantime it's perfectly fine to assign an enum into an
int.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

color: use GIT_COLOR_* instead of numeric constants

Long ago Git's decision to show color for a subsytem was stored in a
tri-state variable: it could be true (1), false (0), or unknown (-1).
But since daa0c3d971 (color: delay auto-color decision until point of
use, 2011-08-17) we want to carry around a new state, "auto", which
bases the decision on the tty-ness of stdout (rather than collapsing
that "auto" state to a true/false immediately).

That commit introduced a set of GIT_COLOR_* defines to represent each
state: UNKNOWN, ALWAYS, NEVER, and AUTO. But it only used the AUTO
value, and left alone code using bare 0/1/-1 values. And of course since
then we've grown many new spots that use those bare values.

Let's switch all of these to use the named constants. That should make
the code a bit easier to read, as it is more obvious that we're
representing a color decision.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/add-i-color' into jk/color-variable-fixes

* jk/add-i-color:
  contrib/diff-highlight: mention interactive.diffFilter
  add-interactive: manually fall back color config to color.ui
  add-interactive: respect color.diff for diff coloring
  stash: pass --no-color to diff plumbing child processes

contrib/diff-highlight: mention interactive.diffFilter

When the README for diff-highlight was written, there was no way to
trigger it for the `add -p` interactive patch mode. We've since grown a
feature to support that, but it was documented only on the Git side.
Let's also let people coming the other direction, from diff-highlight,
know that it's an option.

Suggested-by: Isaac Oscar Gariano <IsaacOscar@live.com.au>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add-interactive: manually fall back color config to color.ui

Color options like color.interactive and color.diff should fall back to
the value of color.ui if they aren't set. In add-interactive, we check
the specific options (e.g., color.diff) via repo_config_get_value(),
which does not depend on the main command having loaded any color config
via the git_config() callback mechanism.

But then we call want_color() on the result; if our specific config is
unset then that function uses the value of git_use_color_default. That
variable is typically set from color.ui by the git_color_config()
callback, which is called by the main command in its own git_config()
callback function.

This works fine for "add -p", whose add_config() callback calls into
git_color_config(). But it doesn't work for other commands like
"checkout -p", which is otherwise unaware of color at all. People tend
not to notice because the default is "auto", and that's what they'd set
color.ui to as well. But something like:

  git -c color.ui=false checkout -p

should disable color, and it doesn't.

This regression goes back to 0527ccb1b5 (add -i: default to the built-in
implementation, 2021-11-30). In the perl version we got the color config
from "git config --get-colorbool", which did the full lookup for us.

The obvious fix is for git-checkout to add a call to git_color_config()
to its own config callback. But we'd have to do so for every command
with this problem, which is error-prone. Let's see if we can fix it more
centrally.

It is tempting to teach want_color() to look up the value of
repo_config_get_value("color.ui") itself. But I think that would have
disastrous consequences. Plumbing commands, especially older ones, avoid
porcelain config like "color.*" by simply not parsing it in their config
callbacks. Looking up the value of color.ui under the hood would
undermine that.

Instead, let's do that lookup in the add-interactive setup code. We're
already demand-loading other color config there, which is probably fine
(even in a plumbing command like "git reset", the interactive mode is
inherently porcelain-ish). That catches all commands that use the
interactive code, whether they were calling git_color_config()
themselves or not.

Reported-by: Isaac Oscar Gariano <isaacoscar@live.com.au>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add-interactive: respect color.diff for diff coloring

The old perl git-add--interactive.perl script used the color.diff config
option to decide whether to color diffs (and if not set, it fell back to
the value of color.ui via git-config's --get-colorbool option). When we
switched to the builtin version, this was lost: we respect only
color.ui. So for example:

  git -c color.diff=false add -p

would color the diff, even when it should not.

The culprit is this line in add-interactive.c's parse_diff():

  if (want_color_fd(1, -1))

That "-1" means "no config has been set", which causes it to fall back
to the color.ui setting. We should instead be passing the value of
color.diff. But the problem is that we never even parse that config
option!

Instead the builtin interactive code parses only the value of
color.interactive, which is used for prompts and other messages. One
could perhaps argue that this should cover interactive diff coloring,
too, but historically it did not. The perl script treated
color.interactive and color.diff separately. So we should grab the
values for both, keeping separate fields in our add_i_state variable,
rather than a single use_color field.

We also load individual color slots (e.g., color.interactive.prompt),
leaving them as the empty string when color is disabled. This happens
via the init_color() helper in add-interactive, which checks that
use_color field. Now that there are two such fields, we need to pass the
appropriate one for each color.

The colors are mostly easy to divide up; color.interactive.* follows
color.interactive, and color.diff.* follows color.diff. But the "reset"
color is tricky. It is used for both types of coloring, but the two can
be configured independently. So we introduce two separate reset colors,
and use each in the appropriate spot.

There are two new tests. The first enables interactive prompt colors but
disables color.diff. We should see a colored prompt but not a colored
diff, showing that we are now respecting color.diff (and not
color.interactive or color.ui).

The second does the opposite. We disable color.interactive but turn on
color.diff with a custom fragment color. When we split a hunk, the
interactive code has to re-color the hunk header, which lets us check
that we correctly loaded the color.diff.frag config based on color.diff,
not color.interactive.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: pass --no-color to diff plumbing child processes

After a partial stash, we may clear out the working tree by capturing
the output of diff-tree and piping it into git-apply (and likewise we
may use diff-index to restore the index). So we most definitely do not
want color diff output from that diff-tree process.  And it normally
would not produce any, since its stdout is not going to a tty, and the
default value of color.ui is "auto".

However, if GIT_PAGER_IN_USE is set in the environment, that overrides
the tty check, and we'll produce a colorized diff that chokes git-apply:

  $ echo y | GIT_PAGER_IN_USE=1 git stash -p
  [...]
  Saved working directory and index state WIP on main: 4f2e2bb foo
  error: No valid patches in input (allow with "--allow-empty")
  Cannot remove worktree changes

Setting this variable is a relatively silly thing to do, and not
something most users would run into. But we sometimes do it in our tests
to stimulate color. And it is a user-visible bug, so let's fix it rather
than work around it in the tests.

The root issue here is that diff-tree (and other diff plumbing) should
probably not ever produce color by default. It does so not by parsing
color.ui, but because of the baked-in "auto" default from 4c7f1819b3
(make color.ui default to 'auto', 2013-06-10). But changing that is
risky; we've had discussions back and forth on the topic over the years.
E.g.:

  https://lore.kernel.org/git/86D0A377-8AFD-460D-A90E-6327C6934DFC@gmail.com/.

So let's accept that as the status quo for now and protect ourselves by
passing --no-color to the child processes. This is the same thing we did
for add-interactive itself in 1c6ffb546b (add--interactive.perl: specify
--no-color explicitly, 2020-09-07).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.51

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge tag 'l10n-2.51.0-2' of https://github.com/git-l10n/git-po

l10n-2.51.0-2

* tag 'l10n-2.51.0-2' of https://github.com/git-l10n/git-po:
  l10n: Update Catalan Translation for Git 2.51-rc2
  l10n: zh_CN: updated translation for 2.51
  l10n: uk: add 2.51 translation
  l10n: zh_TW: Git 2.51
  l10n: po-id for 2.51
  l10n: fr translation update for v2.51.0
  l10n: tr: Update Turkish translations for 2.51.0
  l10n: Updated translation for vi-2.51
  l10n: sv.po: Update Swedish translation
  l10n: bg.po: Updated Bulgarian translation (5856t)

cmake: accommodate for `UNIT_TEST_SOURCES`

As part of 9bbc981c6f2 (t/unit-tests: finalize migration of
reftable-related tests, 2025-07-24), the explicit list of
`UNIT_TEST_PROGRAMS` was turned into a wildcard pattern-derived list.

Let's do the same in the CMake definition.

This fixes build errors with symptoms like this:

  CMake Error at CMakeLists.txt:132 (string):
    string sub-command REPLACE requires at least four arguments.
  Call Stack (most recent call first):
    CMakeLists.txt:1037 (parse_makefile_for_scripts)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: Update Catalan Translation for Git 2.51-rc2

Edit: We are continuing to follow the existing PO file convention, which
includes filenames but strips out line numbers from the file-location
comments. This standard was set by our former lead, Jordi Mas, and we
are maintaining it for project-wide consistency.

Signed-off-by: Mikel Forcada <mikel.forcada@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch 'jx/zh_CN-2.51' of github.com:jiangxin/git

* 'jx/zh_CN-2.51' of github.com:jiangxin/git:
  l10n: zh_CN: updated translation for 2.51

l10n: zh_CN: updated translation for 2.51

Signed-off-by: Teng Long <dyroneteng@gmail.com>
Reviewed-by: Fangyi Zhou <me@fangyi.io>
Reviewed-by: 依云 <lilydjwg@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

Merge branch '2.51-uk-update' of github.com:arkid15r/git-ukrainian-l10n

* '2.51-uk-update' of github.com:arkid15r/git-ukrainian-l10n:
  l10n: uk: add 2.51 translation

l10n: uk: add 2.51 translation

Co-authored-by: Kate Golovanova <kate@kgthreads.com>
Signed-off-by: Arkadii Yakovets <ark@cho.red>
Signed-off-by: Kate Golovanova <kate@kgthreads.com>

Merge branch 'fr_v2.51.0' of github.com:jnavila/git

* 'fr_v2.51.0' of github.com:jnavila/git:
  l10n: fr translation update for v2.51.0

Merge branch 'po-id' of github.com:bagasme/git-po

* 'po-id' of github.com:bagasme/git-po:
  l10n: po-id for 2.51

Merge branch 'tr-l10n' of github.com:bitigchi/git-po

* 'tr-l10n' of github.com:bitigchi/git-po:
  l10n: tr: Update Turkish translations for 2.51.0

Merge branch 'l10n/zh-TW/2025-08-08' of github.com:l10n-tw/git-po

* 'l10n/zh-TW/2025-08-08' of github.com:l10n-tw/git-po:
  l10n: zh_TW: Git 2.51

Merge branch 'master' of github.com:alshopov/git-po

* 'master' of github.com:alshopov/git-po:
  l10n: bg.po: Updated Bulgarian translation (5856t)

Merge branch 'master' of github.com:nafmo/git-l10n-sv

* 'master' of github.com:nafmo/git-l10n-sv:
  l10n: sv.po: Update Swedish translation

Merge branch 'vi-2.51' of github.com:Nekosha/git-po

* 'vi-2.51' of github.com:Nekosha/git-po:
  l10n: Updated translation for vi-2.51

l10n: zh_TW: Git 2.51

Co-authored-by: Lumynous <lumynou5.tw@gmail.com>
Co-authored-by: hms5232 <hms5232@hhming.moe>
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>

l10n: po-id for 2.51

Update following components:

  * add-interactive.c
  * builtin/add.c
  * builtin/config.c
  * builtin/fetch.c
  * builtin/for-each-ref.c
  * builtin/gc.c
  * builtin/merge.c
  * builtin/pack-objects.c
  * builtin/remote.c
  * builtin/repack.c
  * builtin/stash.c
  * builtin/submodule--helper.c
  * diff-no-index.c
  * git-send-email.perl
  * imap-send.c
  * parse-options.c
  * refs.c
  * t/helper/test-path-walk.c
  * usage.c

Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>

l10n: fr translation update for v2.51.0

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>

l10n: tr: Update Turkish translations for 2.51.0

Signed-off-by: Emir SARI <emir_sari@icloud.com>

l10n: Updated translation for vi-2.51

Signed-off-by: Vũ Tiến Hưng <newcomerminecraft@gmail.com>

l10n: sv.po: Update Swedish translation

Also fix typo reported by Tuomas Ahola <taahol@utu.fi>.

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: bg.po: Updated Bulgarian translation (5856t)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

Git 2.51-rc2

Signed-off-by: Junio C Hamano <gitster@pobox.com>

A few hotfixes before -rc2

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rs/merge-compact-summary'

Hotfix.

* rs/merge-compact-summary:
  merge: don't document non-existing --compact-summary argument

Merge branch 'rs/for-each-ref-start-after-marker-fix'

Hotfix.

* rs/for-each-ref-start-after-marker-fix:
  for-each-ref: call --start-after argument "marker"

merge: don't document non-existing --compact-summary argument

3a54f5bd5d (merge/pull: add the "--compact-summary" option, 2025-06-12)
added the option --compact-summary to both merge and pull.  It takes no
no argument, but for merge it got an argument help string.  Remove it,
since it is unnecessary.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

for-each-ref: call --start-after argument "marker"

dabecb9db2 (for-each-ref: introduce a '--start-after' option,
2025-07-15) added the option --start-after and referred to its argument
as "marker" in documentation and usage string, but not in the option's
short help.  Use "marker" there as well for consistency and brevity.

Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.51-rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/RelNotes/2.51.0: improve wording for a couple entries

Improve wording and fix typos for a couple entries part of the Git 2.51
release notes.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jt/archive-zip-deflate-fix'

The deflate codepath in "git archive --format=zip" had a
longstanding bug coming from misuse of zlib API, which has been
corrected.

* jt/archive-zip-deflate-fix:
  archive: flush deflate stream until Z_STREAM_END

Merge branch 'dl/squelch-maybe-uninitialized'

Squelch false-positive compiler warning.

* dl/squelch-maybe-uninitialized:
  t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og
  remote: bail early from set_head() if missing remote name

Merge branch 'jk/revert-squelch-compiler-warning'

Squelch false-positive compiler warning.

* jk/revert-squelch-compiler-warning:
  revert: initialize const value

A bit more after -rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'kj/renamed-submodule'

The case where a new submodule takes a path where used to be a
completely different subproject is now dealt a bit better than
before.

* kj/renamed-submodule:
  fixup! submodule: skip redundant active entries when pattern covers path
  fixup! submodule: prevent overwriting .gitmodules on path reuse
  submodule: skip redundant active entries when pattern covers path
  submodule: prevent overwriting .gitmodules on path reuse

Merge branch 'rs/tighten-alias-help'

"git -c alias.foo=bar foo -h baz" reported "'foo' is aliased to
'bar'" and then went on to run "git foo -h baz", which was
unexpected.  Tighten the rule so that alias expansion is reported
only when "-h" is the sole option.

* rs/tighten-alias-help:
  git: show alias info only with lone -h

Merge branch 'ps/object-file-wo-the-repository'

Reduce implicit assumption and dependence on the_repository in the
object-file subsystem.

* ps/object-file-wo-the-repository:
  object-file: get rid of `the_repository` in index-related functions
  object-file: get rid of `the_repository` in `force_object_loose()`
  object-file: get rid of `the_repository` in `read_loose_object()`
  object-file: get rid of `the_repository` in loose object iterators
  object-file: remove declaration for `for_each_file_in_obj_subdir()`
  object-file: inline `for_each_loose_file_in_objdir_buf()`
  object-file: get rid of `the_repository` when writing objects
  odb: introduce `odb_write_object()`
  loose: write loose objects map via their source
  object-file: get rid of `the_repository` in `finalize_object_file()`
  object-file: get rid of `the_repository` in `loose_object_info()`
  object-file: get rid of `the_repository` when freshening objects
  object-file: inline `check_and_freshen()` functions
  object-file: get rid of `the_repository` in `has_loose_object()`
  object-file: stop using `the_hash_algo`
  object-file: fix -Wsign-compare warnings

t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og

When building with -Og on gcc 15.1.1, the build produces a warning. In
practice, though, this cannot be hit because `exact` acts as a guard and
that variable can only be set after `matchlen` is already initialized

Assign a default value to `matchlen` so that the warning is silenced.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: bail early from set_head() if missing remote name

In "git remote set-head", we can take varying numbers of arguments
depending on whether we saw the "-d" or "-a" options. But the first
argument is always the remote name.

The current code is somewhat awkward in that it conditionally handles
the remote name up-front like this:

  if (argc)
     remote = ...from argv[0]...

and then only later decides to bail if we do not have the right number
of arguments for the options we saw.

This makes it hard to figure out if "remote" is always set when it needs
to be. Both for humans, but also for compilers; with -Og, gcc complains
that "remote" can be accessed without being initialized (although this
is not true, as we'd always die with a usage message in that case).

Let's instead enforce the presence of the remote argument up front,
which fixes the compiler warning and is easier to understand. It does
mean duplicating the code to print a usage message, but it's a single
line.

Noticed-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: flush deflate stream until Z_STREAM_END

In `archive-zip.c:write_zip_entry()` when using a stream as input for
deflating a file, the call to `git_deflate()` with Z_FINISH always
expects Z_STREAM_END to be returned. Per zlib documentation[1]:

        If the parameter flush is set to Z_FINISH, pending input is
        processed, pending output is flushed and deflate returns with
        Z_STREAM_END if there was enough output space. If deflate
        returns with Z_OK or Z_BUF_ERROR, this function must be called
        again with Z_FINISH and more output space (updated avail_out)
        but no more input data, until it returns with Z_STREAM_END or an
        error. After deflate has returned Z_STREAM_END, the only
        possible operations on the stream are deflateReset or
        deflateEnd.

In scenarios where the output buffer is not large enough to write all
the compressed data, it is perfectly valid for the underlying
`deflate()` to return Z_OK. Thus, expecting a single pass of `deflate()`
here to always return Z_STREAM_END is a bug. Update the code to flush
the deflate stream until Z_STREAM_END is returned.

[1]: https://zlib.net/manual.html

Helped-by: Toon Claes <toon@iotcl.com>
Signed-off-by: Justin Tobler <jltobler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of https://github.com/j6t/git-gui

* 'master' of https://github.com/j6t/git-gui: (21 commits)
  git-gui: ensure own version of git-gui--askpass is used
  git-gui: Allow Tcl 9.0
  git-gui: use -profile tcl8 on encoding conversions
  git-gui: use -profile tcl8 for file input with Tcl 9
  git-gui: themed.tcl: use full namespace for color
  git-gui: remove EOL translation for gets
  git-gui: honor TCLTK_PATH in git-gui--askpass
  git-gui: retire Git Gui.app
  git-gui: fix dependency of GITGUI_MAIN on generator
  git-gui: remove uname_O in Makefile
  git-gui i18n: Remove the locations within the Bulgarian translation
  git-gui i18n: Update Bulgarian translation (557t)
  git-gui: do not mix -translation binary and -encoding
  git-gui: replace encoding binary with iso8859-1
  git-gui: translation binary defines iso8859-1
  git-gui: assure -eofchar {} on all channels
  git-gui: use /cmd/git-gui.exe for shortcut
  git-gui: Windows tk_getSaveFile is not useful for shortcuts
  git-gui: let nice work on Windows
  git-gui: do not add directories to PATH on Windows
  ...

Merge branch 'master' of https://github.com/j6t/gitk

* 'master' of https://github.com/j6t/gitk:
  gitk: Mention globs in description of preference to hide custom refs
  gitk: filter invisible upstream refs from reference list
  gitk: avoid duplicated upstream refs
  gitk i18n: Remove the locations within the Bulgarian translation
  gitk i18n: Update Bulgarian translation (322t)
  gitk: allow Tcl/Tk 9.0+
  gitk: use -profile tcl8 on encoding conversions
  gitk: use -profile tcl8 for file input with Tcl 9
  gitk: Tcl9 doesn't expand ~, use $env(HOME)
  gitk: switch to -translation binary
  gitk: update scrolling for TclTk 8.7+ / TIP 474
  gitk: restore ui colors after cancelling config dialog
  gitk: set config dialog color swatches in one place
  gitk: Add user preference to hide specific references

Merge branch 'cb/no-tcl86-on-macos'

* cb/no-tcl86-on-macos:
  git-gui: ensure own version of git-gui--askpass is used
  git-gui: honor TCLTK_PATH in git-gui--askpass
  git-gui: retire Git Gui.app
  git-gui: fix dependency of GITGUI_MAIN on generator
  git-gui: remove uname_O in Makefile

git-gui: ensure own version of git-gui--askpass is used

When finding a location for the askpass helper, git will be asked
for its exec path, but if that git is not the same that called
git-gui then we might mistakenly point to its helper instead.

Assume that git-gui and the helper are colocated to derive its
path instead.

This is specially useful in macOS where a broken version of that
helper is provided by the system git.

[j6t: move directory to variable to help in-flight topics]

Suggested-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Merge branch 'docglobs' of github.com:ilyagr/gitk

* 'docglobs' of github.com:ilyagr/gitk:
  gitk: Mention globs in description of preference to hide custom refs

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Git 2.51-rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jc/test-hashmap-is-still-here'

Comment fix.

* jc/test-hashmap-is-still-here:
  test-hashmap: document why it is no longer used but still there

Merge branch 'kh/doc-fast-import-historical'

Doc update.

* kh/doc-fast-import-historical:
  doc: fast-import: contextualize the hardware cost

Merge branch 'ms/meson-with-ancient-git-wo-ls-files-dedup'

Build fix.

* ms/meson-with-ancient-git-wo-ls-files-dedup:
  meson: tolerate errors from git ls-files --deduplicate

Merge branch 'jc/doc-release-vs-clear'

Doc update.

* jc/doc-release-vs-clear:
  CodingGuidelines: clarify that S_release() does not reinitialize

Merge branch 'ch/t7450-recursive-clone-test-fix'

Test fix.

* ch/t7450-recursive-clone-test-fix:
  t7450: inspect the correct path a broken code would write to

Merge branch 'js/prompt-crlf-fix'

Interactive prompt code did not correctly strip CRLF from the end
of line on Windows.

* js/prompt-crlf-fix:
  interactive: do strip trailing CRLF from input

Merge branch 'ps/meson-clar-decls-fix'

Build fix.

* ps/meson-clar-decls-fix:
  meson: ensure correct "clar-decls.h" header is used

Merge branch 'js/mingw-fixes'

Windows fixes.

* js/mingw-fixes:
  mingw: support Windows Server 2016 again
  mingw_rename: support ReFS on Windows 2022
  mingw: drop Windows 7-specific work-around
  mingw_open_existing: handle directories better

Merge branch 'lm/add-p-context'

"git add/etc -p" now honor the diff.context configuration variable,
and also they learn to honor the -U<n> command-line option.

* lm/add-p-context:
  add-patch: add diff.context command line overrides
  add-patch: respect diff.context configuration
  t: use test_config in t4055
  t: use test_grep in t3701 and t4055

Merge branch 'ps/config-wo-the-repository'

The config API had a set of convenience wrapper functions that
implicitly use the_repository instance; they have been removed and
inlined at the calling sites.

* ps/config-wo-the-repository: (21 commits)
  config: fix sign comparison warnings
  config: move Git config parsing into "environment.c"
  config: remove unused `the_repository` wrappers
  config: drop `git_config_set_multivar()` wrapper
  config: drop `git_config_get_multivar_gently()` wrapper
  config: drop `git_config_set_multivar_in_file_gently()` wrapper
  config: drop `git_config_set_in_file_gently()` wrapper
  config: drop `git_config_set()` wrapper
  config: drop `git_config_set_gently()` wrapper
  config: drop `git_config_set_in_file()` wrapper
  config: drop `git_config_get_bool()` wrapper
  config: drop `git_config_get_ulong()` wrapper
  config: drop `git_config_get_int()` wrapper
  config: drop `git_config_get_string()` wrapper
  config: drop `git_config_get_string()` wrapper
  config: drop `git_config_get_string_multi()` wrapper
  config: drop `git_config_get_value()` wrapper
  config: drop `git_config_get_value()` wrapper
  config: drop `git_config_get()` wrapper
  config: drop `git_config_clear()` wrapper
  ...

Merge branch 'kn/for-each-ref-skip-updates'

Code clean-up.

* kn/for-each-ref-skip-updates:
  ref-filter: use REF_ITERATOR_SEEK_SET_PREFIX instead of '1'
  t6302: add test combining '--start-after' with '--exclude'
  for-each-ref: reword the documentation for '--start-after'
  for-each-ref: fix documentation argument ordering
  ref-cache: use 'size_t' instead of int for length

Merge branch 'jt/switch-restore-no-longer-experimental'

"git switch" and "git restore" are declared to be no longer
experimental.

* jt/switch-restore-no-longer-experimental:
  builtin: unmark git-switch and git-restore as experimental

Merge branch 'jb/t7510-gpg-program-path'

A new test to ensure that a recent change will keep working.

* jb/t7510-gpg-program-path:
  t7510: use $PWD instead of $(pwd) inside PATH
  t7510: add test cases for non-absolute gpg program

Merge branch 'cc/t9350-cleanup'

Test clean-up.

* cc/t9350-cleanup:
  t9350: redirect input to only fast-import

Merge branch 'hy/blame-simplify-get-commit-info'

Code simplification.

* hy/blame-simplify-get-commit-info:
  blame: remove parameter detailed in get_commit_info()

revert: initialize const value

When building with clang-22 and DEVELOPER=1 mode, this warning causes us
to fail compilation:

  builtin/revert.c:114:13: error: default initialization of an object of type 'const char' leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe]
    114 |         const char sentinel_value;
        |                    ^

The compiler is right that this code is a bit funny. We declare a const
value without an initializer. It cannot be assigned to because of the
const, but without an initializer it has no predictable value. So as a
variable it can never have any useful function, and if we tried to look
at it, we'd get undefined behavior.

But it does have a function. We never use its value, but rather use its
address as a sentinel value for some other variables:

        const char *gpg_sign = &sentinel_value;

...maybe set gpg_sign via parse_options...

if (gpg_sign != &sentinel_value)
...we got a non-default value...

Normally we'd use NULL as a sentinel value for a pointer, but it doesn't
work here because we also want to detect --no-gpg-sign, which is marked
by setting the pointer to NULL. We need a separate "this was not
touched" value, which is what this sentinel variable gives us.

So the code is correct as-is, but the sentinel variable itself is funny
enough that it's understandable for a compiler warning to flag it. Let's
try to appease the compiler.

There are a few possible options:

  1. Instead of a variable, we could just construct an artificial
     sentinel address like "1", "-1", etc. I think these technically
     fall afoul of the C standard (even if we do not access them, even
     constructing invalid pointers is not always allowed). But it's also
     something we do elsewhere, and even happens in some standard
     interfaces (e.g., mmap()'s MMAP_FAILED value). It does involve some
     annoying casts, though.

  2. We can mark it as static. That gives it a definite value, but
     perhaps makes people wonder if the static-ness is important, when
     it's not.

  3. We can just give it a value to shut the compiler up, even though
     nobody cares about that value.

I went with (3) here as the smallest and most obvious change.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitk: Mention globs in description of preference to hide custom refs

This clarifies that one has to enter e.g. `jj/keep/*` and not just
`jj/keep`.

Follows up on 2441e19.

Signed-off-by: Ilya Grigoriev <ilyagr@users.noreply.github.com>

The seventeenth batch, just before -rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'hl/test-helper-fd-close'

A few file descriptors left unclosed upon program completion in a
few test helper programs are now closed.

* hl/test-helper-fd-close:
  test-delta: close output descriptor after use
  test-delta: use strbufs to hold input files
  test-delta: handle errors with die()
  t/helper/test-truncate: close file descriptor after truncation

Merge branch 'ow/rebase-verify-insn-fmt-before-initializing-state'

"git rebase -i" with bogus rebase.instructionFormat configuration
failed to produce the todo file after recording the state files,
leading to confused "git status"; this has been corrected.

* ow/rebase-verify-insn-fmt-before-initializing-state:
  rebase: write script before initializing state

Merge branch 'ps/object-store-midx'

Redefine where the multi-pack-index sits in the object subsystem,
which recently was restructured to allow multiple backends that
support a single object source that belongs to one repository.  A
midx does span mulitple "object sources".

* ps/object-store-midx:
  midx: remove now-unused linked list of multi-pack indices
  packfile: stop using linked MIDX list in `get_all_packs()`
  packfile: stop using linked MIDX list in `find_pack_entry()`
  packfile: refactor `get_multi_pack_index()` to work on sources
  midx: stop using linked list when closing MIDX
  packfile: refactor `prepare_packed_git_one()` to work on sources
  midx: start tracking per object database source

Merge branch 'kn/for-each-ref-skip'

"git for-each-ref" learns "--start-after" option to help
applications that want to page its output.

* kn/for-each-ref-skip:
  ref-cache: set prefix_state when seeking
  for-each-ref: introduce a '--start-after' option
  ref-filter: remove unnecessary else clause
  refs: selectively set prefix in the seek functions
  ref-cache: remove unused function 'find_ref_entry()'
  refs: expose `ref_iterator` via 'refs.h'

mingw: support Windows Server 2016 again

It was reported to the Git for Windows project that a simple `git init`
fails on Windows Server 2016:

  D:\Dev\test> git init
  error: could not write config file D:/Dev/test/.git/config: Function not implemented
  fatal: could not set 'core.repositoryformatversion' to '0'

According to https://endoflife.date/windows-server, Windows Server 2016
is officially supported for another one-and-a-half years as of time of
writing, so this is not good.

The culprit is the `mingw_rename()` changes that try to use POSIX
semantics when available, but fail to fall back properly on Windows
Server 2016.

This fixes https://github.com/git-for-windows/git/issues/5695.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw_rename: support ReFS on Windows 2022

ReFS is an alternative filesystem to NTFS. On Windows 2022, it seems not
to support the rename operation using POSIX semantics that Git uses on
Windows as of 391bceae4350 (compat/mingw: support POSIX semantics for
atomic renames, 2024-10-27).

However, Windows 2022 reports `ERROR_NOT_SUPPORTED` in this instance.
This is in contrast to `ERROR_INVALID_PARAMETER` (as previous Windows
versions would report that do not support POSIX semantics in renames at
all).

Let's handle both errors the same: by falling back to the best-effort
option, namely to rename without POSIX semantics.

This fixes https://github.com/git-for-windows/git/issues/5427

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: drop Windows 7-specific work-around

In ac33519ddfa8 (mingw: restrict file handle inheritance only on Windows
7 and later, 2019-11-22), I introduced code to safe-guard the
defense-in-depth handling that restricts handles' inheritance so that it
would work with Windows 7, too.

Let's revert this patch: Git for Windows dropped supporting Windows 7 (and
Windows 8) directly after Git for Windows v2.46.2. For full details, see
https://gitforwindows.org/requirements#windows-version.

Actually, on second thought: revert only the part that makes this handle
inheritance restriction logic optional and that suggests to open a bug
report if it fails, but keep the fall-back to try again without said
logic: There have been a few false positives over the past few years
(where the warning was triggered e.g. because Defender was still
accessing a file that Git wanted to overwrite), and the fall-back logic
seems to have helped occasionally in such situations.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw_open_existing: handle directories better

CreateFileW() requires FILE_FLAG_BACKUP_SEMANTICS to create a directory
handle [1] and errors out with ERROR_ACCESS_DENIED without this flag.
Fall back to accessing Directory handles this way.

[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#directories

This fixes https://github.com/git-for-windows/git/issues/5068

Signed-off-by: Matthias Aßhauer <mha1993@live.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'strip-post-hooks' of github.com:orgads/git-gui

* 'strip-post-hooks' of github.com:orgads/git-gui:
  git-gui: strip the commit message after running commit-msg hook

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Merge branch 'ml/tcl90'

* ml/tcl90:
  git-gui: Allow Tcl 9.0
  git-gui: use -profile tcl8 on encoding conversions
  git-gui: use -profile tcl8 for file input with Tcl 9
  git-gui: themed.tcl: use full namespace for color
  git-gui: remove EOL translation for gets
  git-gui: do not mix -translation binary and -encoding
  git-gui: replace encoding binary with iso8859-1
  git-gui: translation binary defines iso8859-1
  git-gui: assure -eofchar {} on all channels

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

Merge branch 'master' of https://github.com/alshopov/git-gui

* 'master' of https://github.com/alshopov/git-gui:
  git-gui i18n: Remove the locations within the Bulgarian translation
  git-gui i18n: Update Bulgarian translation (557t)

Signed-off-by: Johannes Sixt <j6t@kdbg.org>

The sixteenth batch

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'sk/reftable-clarify-tests'

The reftable unit tests are now ported to the "clar" unit testing
framework.

* sk/reftable-clarify-tests:
  t/unit-tests: finalize migration of reftable-related tests
  t/unit-tests: convert reftable stack test to use clar
  t/unit-tests: convert reftable record test to use clar
  t/unit-tests: convert reftable readwrite test to use clar
  t/unit-tests: convert reftable table test to use clar
  t/unit-tests: convert reftable pq test to use clar
  t/unit-tests: convert reftable merged test to use clar
  t/unit-tests: convert reftable block test to use clar
  t/unit-tests: convert reftable basics test to use clar test framework
  t/unit-tests: implement clar specific reftable test helper functions

Merge branch 'ly/pull-autostash'

"git pull" learned to pay attention to pull.autostash configuration
variable, which overrides rebase/merge.autostash.

* ly/pull-autostash:
  pull: add pull.autoStash config option

Merge branch 'jc/document-test-balloons-in-flight'

To help our developers, document what C99 language features are
being considered for adoption, in addition to what past experiments
have already decided.

* jc/document-test-balloons-in-flight:
  CodingGuidelines: document test balloons in flight

Merge branch 'ag/imap-send-list-folders-doc'

Document recently added "git imap-send --list" with an example.

* ag/imap-send-list-folders-doc:
  docs: explain how to use `git imap-send --list` command to get a list of available folders

Merge branch 'cb/meson-avoid-broken-macos-pcre2'

Build fix for macOS.

* cb/meson-avoid-broken-macos-pcre2:
  meson: work around broken system PCRE2 dependency in macOS

Merge branch 'jc/ci-print-test-failures-fix'

CI fix.

* jc/ci-print-test-failures-fix:
  ci: allow github-actions print test failures again

Merge branch 'jk/unleak-reflog-expire-entry'

Leakfix.

* jk/unleak-reflog-expire-entry:
  reflog: close leak of reflog expire entry

Merge branch 'jc/do-not-scan-argv-without-parsing'

Update a hard-to-read in-code NEEDSWORK comment.

* jc/do-not-scan-argv-without-parsing:
  rev-list: update a NEEDSWORK comment

Merge branch 'jk/revision-no-early-output'

Remove unsupported, unused, and unsupportable old option from "git
log".

* jk/revision-no-early-output:
  revision: drop early output option

Merge branch 'jc/rev-list-info-cleanup'

Move structure definition from unrelated header file to where it
belongs.

* jc/rev-list-info-cleanup:
  rev-list: make "struct rev_list_info" static to the only user