commit-graph: fix writing generations with dates exceeding 34 bits
The `timestamp_t` type is declared as `uintmax_t` and thus typically has
64 bits of precision. Usually, the full precision of such dates is not
required: it would be comforting to know that Git is still around in
millions of years, but all in all the chance is rather low.
We abuse this fact in the commit-graph: instead of storing the full 64
bits of precision, committer dates only store 34 bits. This is still
plenty of headroom, as it means that we can represent dates until year
2514. Commits which are dated beyond that year will simply get a date
whose remaining bits are masked.
The result of this is somewhat curious: the committer date will be
different depending on whether a commit gets parsed via the commit-graph
or via the object database. This isn't really too much of an issue in
general though, as we don't typically use the date parsed from the
commit-graph in user-facing output.
But with 024b4c9697 (commit: make `repo_parse_commit_no_graph()` more
robust, 2026-02-16) it started to become a problem when writing the
commit-graph itself. This commit changed `repo_parse_commit_no_graph()`
so that we re-parse the commit via the object database in case it was
already parsed beforehand via the commit-graph.
The consequence is that we may now act with two different commit dates
at different stages:
- Initially, we use the 34-bit precision timestamp when writing the
chunk generation data. We thus correctly compute the offsets
relative to the on-disk timestamp here.
- Later, when writing the overflow data, we may end up with the
full-precision timestamp. When the date is larger than 34 bits the
result of this is an underflow when computing the offset.
This causes a mismatch in the number of generation data overflow records
we want to write, and that ultimately causes Git to die.
Introduce a new helper function that computes the generation offset for
a commit while correctly masking the date to 34 bits. This makes the
previously-implicit assumptions about the commit date precision explicit
and thus hopefully less fragile going forward.
Adapt sites that compute the offset to use the function.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
K Jayatheerth [Tue, 24 Mar 2026 01:57:33 +0000 (07:27 +0530)]
remote-curl: fall back to default hash outside repo
When a remote helper like git-remote-http is invoked outside of a
repository (for example, by running git ls-remote in a non-git
directory), setup_git_directory_gently() leaves the_hash_algo
uninitialized as NULL.
If the user has a globally configured fetch refspec, remote-curl
attempts to parse it during initialization. Inside parse_refspec(),
it checks whether the LHS of the refspec is an exact OID by evaluating
llen == the_hash_algo->hexsz. Because the_hash_algo is NULL, this
results in a segmentation fault.
In 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside of a repo,
2024-08-02), we added a workaround to ls-remote to fall back to the
default hash algorithm to prevent exactly this type of crash when
parsing refspec capabilities. However, because remote-curl runs as a
separate process, it does not inherit that fallback and crashes anyway.
Instead of pushing a NULL-guard workaround down into parse_refspec(),
fix this by mirroring the ls-remote workaround directly in
remote-curl.c. If we are operating outside a repository, initialize
the_hash_algo to GIT_HASH_DEFAULT. This keeps the HTTP transport
consistent with non-HTTP transports that execute in-process, preventing
crashes without altering the generic refspec parsing logic.
Reported-by: Jo Liss <joliss@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mirko Faina [Mon, 23 Mar 2026 16:57:34 +0000 (17:57 +0100)]
format-patch: add preset for --commit-list-format
"git format-patch --commit-list-format" enables the user to make their
own format for the commit list in the cover letter. It would be nice to
have a ready to use format to replace shortlog.
Teach make_cover_letter() the "modern" format preset.
This new format is the same as: "log:[%(count)/%(total)] %s".
Signed-off-by: Mirko Faina <mroik@delayed.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mirko Faina [Mon, 23 Mar 2026 16:57:32 +0000 (17:57 +0100)]
format.commitListFormat: strip meaning from empty
The configuration variable format.commitListFormat allows for an empty
value. This is unusual and can create issues when interacting with this
configuration variable through the CLI.
Strip meaning to format.commitListFormat with an empty value.
Signed-off-by: Mirko Faina <mroik@delayed.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mirko Faina [Mon, 23 Mar 2026 16:57:31 +0000 (17:57 +0100)]
docs/pretty-formats: add %(count) and %(total)
When --commit-list-format was introduced to format-patch, two new
placeholders were added to the PRETTY FORMATS code without being
documented. Do so now.
Signed-off-by: Mirko Faina <mroik@delayed.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mirko Faina [Mon, 23 Mar 2026 16:57:30 +0000 (17:57 +0100)]
format-patch: rename --cover-letter-format option
To align the name of the configuration variable and the name of the
command line option, either one should change name. By changing the name
of the option we get the added benefit of having --cover-<TAB> expand to
--cover-letter without ambiguity.
If the user gives the --cover-letter-format option it would be
reasonable to expect that the user wants to generate the cover letter
despite not giving --cover-letter.
Rename --cover-letter-format to --commit-list-format and make it imply
--cover-letter unless --no-cover-letter is given.
Signed-off-by: Mirko Faina <mroik@delayed.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 23 Mar 2026 16:20:31 +0000 (09:20 -0700)]
Merge branch 'bb/imap-send-openssl-4.0-prep'
"imap-send" used to use functions whose use is going to be removed
with OpenSSL 4.0; rewrite them using public API that has been
available since OpenSSL 1.1 since 2016 or so.
* bb/imap-send-openssl-4.0-prep:
imap-send: move common code into function host_matches()
imap-send: use the OpenSSL API to access the subject common name
imap-send: use the OpenSSL API to access the subject alternative names
builtin/fsck: stop using `the_repository` in error reporting
In the preceding commit we have introduced the repository into `struct
fsck_object_report`. This allows us to drop remaining uses of the global
`the_repository` variable.
Drop them and remove `USE_THE_REPOSITORY_VARIABLE`.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fsck: stop using `the_repository` when checking packed objects
We implicitly rely on `the_repository` when checking objects part of a
packfile. These objects are iterated over via `verify_pack()`, which is
provided by the packfile subsystem, and a callback function is then
invoked for each of the objects in that specific pack.
Unfortunately, it is not possible to provide a payload to the callback
function. Refactor `verify_pack()` to accept a payload that is passed
through to the callback so that we can inject the repository and get rid
of the use of `the_repository`.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fsck: stop using `the_repository` with loose objects
We depend on `the_repository` when performing consistency checks for
loose objects. Refactor this to use a context-provided repository
instead that is injected via the `struct for_each_loose_cb`.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fsck: stop using `the_repository` when snapshotting refs
We depedn on `the_repository` when snapshotting refs. Refactor this to
use a context-provided repository instead that is injected via the
`struct snapshot_ref_data`.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/fsck: fix trivial dependence on `the_repository`
We have a bunch of sites in "builtin/fsck.c" that depend on
`the_repository` even though we already have a repository available, or
in cases where we can trivially make it available.
Refactor such sites to use the context-provided repository instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fsck subsystem relies on `the_repository` quite a bit. While we
could of course explicitly pass a repository down the callchain, we
already have a `struct fsck_options` that we pass to almost all
functions.
Extend the options to also store the repository to make it readily
available.
Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We initialize the `struct fsck_options` via a set of macros, often in
global scope. In the next commit though we're about to introduce a new
repository field to the options that must be initialized, and naturally
we don't have a repo other than `the_repository` available in this
scope.
Refactor the code to instead intrdouce a new `fsck_options_init()`
function that initializes the options for us and move initialization
into function scope.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When fetching a packfile, we optionally verify received objects via the
fsck subsystem. The options for those consistency checks are declared in
global scope without a good reason, and they are never cleaned up. So in
case the options are reused, they may accumulate more state over time.
Furthermore, in subsequent changes we'll introduce a repository pointer
into the structure. Obviously though, we don't have a repository
available at static time, except for `the_repository`, which we don't
want to use here.
Refactor the code to move the options into the respective functions and
properly manage their lifecycle.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:18 +0000 (02:02 -0400)]
diff-highlight: fetch all config with one process
When diff-highlight was written, there was no way to fetch multiple
config keys _and_ have them interpreted as colors. So we were stuck
with either invoking git-config once for each config key, or fetching
them all and converting human-readable color names into ANSI codes
ourselves.
I chose the former, but it means that diff-highlight kicks off 6
git-config processes (even if you haven't configured anything, it has to
check each one).
Note that any callers which pass in colors directly to the module via
@OLD_HIGHLIGHT and @NEW_HIGHLIGHT (like diff-so-fancy plans to do) are
unaffected; those colors suppress any config lookup we'd do ourselves.
You can see the effect like:
# diff-highlight suppresses git-config's stderr, so dump
# trace through descriptor 3
git show d1f33c753d | GIT_TRACE=3 diff-highlight 3>&2 >/dev/null
which drops from 6 lines down to 1.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scott Baker [Mon, 23 Mar 2026 06:02:15 +0000 (02:02 -0400)]
diff-highlight: allow module callers to pass in color config
Users of the module may want to pass in their own color config for a few
obvious reasons:
- they are pulling the config from different variables than
diff-highlight itself uses
- they are loading the config in a more efficient way (say, by parsing
git-config --list) and don't want to incur the six (!) git-config
calls that DiffHighlight.pm runs to check all config
Let's allow users of the module to pass in the color config, and
lazy-load it when needed if they haven't.
Signed-off-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:13 +0000 (02:02 -0400)]
diff-highlight: test color config
We added configurable colors long ago in bca45fbc1f (diff-highlight:
allow configurable colors, 2014-11-20), but never actually tested it.
Since we'll be touching the color code in a moment, this is a good time
to beef up the tests.
Note that we cover both the highlight/reset style used by the default
colors, as well as the normal/highlight style added by that commit
(which was previously totally untested).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:10 +0000 (02:02 -0400)]
diff-highlight: use test_decode_color in tests
The diff-highlight tests use raw color bytes when comparing expected and
actual output. Let's use test_decode_color, which is our usual technique
in other tests. It makes reading test output diffs a bit easier, since
you're not relying on your terminal to interpret the result (or worse,
interpreting characters yourself via "cat -A").
This will also make it easier to add tests with new colors/attributes,
without having to pre-define the byte sequences ourselves.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:07 +0000 (02:02 -0400)]
t: add matching negative attributes to test_decode_color
Most of the ANSI color attributes have an "off" variant. We don't use
these yet in our test suite, so we never bothered to decode them. Add
the ones that match the attributes we encode so we can make use of them.
There are even more attributes not covered on the positive side, so this
is meant to be useful but not all-inclusive.
Note that "nobold" and "nodim" are the same code, so I've decoded this
as "normal intensity".
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:02:05 +0000 (02:02 -0400)]
diff-highlight: check diff-highlight exit status in tests
When testing diff-highlight, we pipe the output through a sanitizing
function. This loses the exit status of diff-highlight itself, which
could mean we are missing cases where it crashes or exits unexpectedly.
Use an extra tempfile to avoid the pipe.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Scott Baker [Mon, 23 Mar 2026 06:02:02 +0000 (02:02 -0400)]
diff-highlight: drop perl version dependency back to 5.8
The diff-highlight code does not rely on any perl features beyond what
perl 5.8 provides. We bumped it to v5.26 along with the rest of the
project's perl scripts in 702d8c1f3b (Require Perl 5.26.0, 2024-10-23).
There's some value in just having a uniform baseline for the project,
but I think diff-highlight is special here:
- it's in a contrib/ directory that is not frequently touched, so
there is little risk of Git developers getting annoyed that modern
perl features are not available
- it provides a module used by other projects. In particular,
diff-so-fancy relies on DiffHighlight.pm but does not otherwise
require a perl version more modern than 5.8.
Let's drop back to the more conservative requirement.
Signed-off-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 23 Mar 2026 06:01:58 +0000 (02:01 -0400)]
diff-highlight: mention build instructions
Once upon a time, this was just a script in a directory that could be
run directly. That changed in 0c977dbc81 (diff-highlight: split code
into module, 2017-06-15). Let's update the README to make it more clear
that you need to run make.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 21 Mar 2026 16:25:58 +0000 (09:25 -0700)]
Merge branch 'master' of https://github.com/j6t/git-gui
* 'master' of https://github.com/j6t/git-gui:
git-gui: grey out comment lines in commit message
git-gui: wire up "git-gui--askyesno" with Meson
git-gui: massage "git-gui--askyesno" with "generate-script.sh"
git-gui: prefer shell at "/bin/sh" with Meson
git-gui: fix use of GIT_CEILING_DIRECTORIES
git-gui: shift tabstops to account for the first column of patch text
Junio C Hamano [Sat, 21 Mar 2026 16:25:10 +0000 (09:25 -0700)]
Merge branch 'master' of https://github.com/j6t/gitk
* 'master' of https://github.com/j6t/gitk:
gitk: l10n: make PO headers identify the Gitk project
gitk: ignore generated POT file
gitk: i18n: use "Gitk" as package name in POT file
gitk: commit translation files without file information
gitk: support link color in the Preferences dialog
gitk: use config settings for head/tag colors
Introduce a new generic `odb_find_abbrev_len()` function as well as
source-specific callback functions. This makes the logic to compute the
required prefix length to make a given object unique fully pluggable.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
object-file: move logic to compute packed abbreviation length
Same as the preceding commit, move the logic that computes the minimum
required prefix length to make a given object ID unique for the packfile
store into a new function `packfile_store_find_abbrev_len()` that is
part of "packfile.c". This prepares for making the logic fully generic
via pluggable object databases.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
object-name: move logic to compute loose abbreviation length
The function `repo_find_unique_abbrev_r()` takes as input an object ID
as well as a minimum object ID length and returns the minimum required
prefix to make the object ID unique.
The logic that computes the abbreviation length for loose objects is
deeply tied to the loose object storage format. As such, it would fail
in case a different object storage format was used.
Prepare for making this logic generic to the backend by moving the logic
into a new `odb_source_loose_find_abbrev_len()` function that is part of
"object-file.c".
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function `extend_abbrev_len()` computes the length of common hex
characters between two object IDs. This is done by:
- Making the caller provide the `hex` string for the needle object ID.
- Comparing every hex position of the haystack object ID with
`get_hex_char_from_oid()`.
Turning the binary representation into hex first is roundabout though:
we can simply compare the binary representation and give some special
attention to the final nibble.
Introduce a new function `oid_common_prefix_hexlen()` that does exactly
this and refactor the code to use the new function. This allows us to
drop the `struct min_abbrev_data::hex` field. Furthermore, this function
will be used in by some other callsites in subsequent commits.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
object-name: abbreviate loose object names without `disambiguate_state`
The function `find_short_object_filename()` takes an object ID and
computes the minimum required object name length to make it unique. This
is done by reusing the object disambiguation infrastructure, where we
iterate through every loose object and then update the disambiguate
state one by one.
Ultimately, we don't care about the disambiguate state though. It is
used because this infrastructure knows how to enumerate only those
objects that match a given prefix. But now that we have extended the
`odb_for_each_object()` function to do this for us we have an easier way
to do this. Consequently, we really only use the disambiguate state now
to propagate `struct min_abbrev_data`.
Refactor the code and drop this indirection so that we use `struct
min_abbrev_data` directly. This also allows us to drop some now-unused
logic from the disambiguate infrastructure.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
object-name: merge `update_candidates()` and `match_prefix()`
There's only a single callsite for `match_prefix()`, and that function
is a rather trivial wrapper of `update_candidates()`. Merge these two
functions into a single `update_disambiguate_state()` function.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function `get_short_oid()` takes as input an abbreviated object ID
and tries to turn that object ID into the full object ID. This is done
by iterating through all objects that have the user-provided prefix. If
that yields exactly one object we know that the abbreviated object ID is
unambiguous, otherwise it is ambiguous and we print the list of objects
that match the prefix.
We iterate through all objects with the given prefix by calling both
`find_short_packed_object()` and `find_short_object_filename()`, which
is of course specific to the "files" backend. But we now have a generic
way to iterate through objects with a specific prefix.
Refactor the code to use `odb_for_each_object()` instead so that it
works with object backends different than the "files" backend.
Remove the now-unused `find_short_packed_object()` function.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function `repo_collect_ambiguous()` is responsible for collecting
objects whose IDs match a specific prefix. The information is then
used to inform the user about which objects they could have meant in
case a short object ID is ambiguous.
The logic to do this uses the object disambiguation infrastructure and
calls into backend-specific functions to iterate through loose and
packed objects. This isn't really required anymore though: all we want
to do is to enumerate objects that have such a prefix and then append
those objects to a `struct oid_array`. This can be trivially achieved
in a generic way now that `odb_for_each_object()` has learned to yield
only objects that match such a prefix.
Refactor the code to use the backend-generic infrastructure instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
object-name: move logic to iterate through loose prefixed objects
The logic to iterate through loose objects that have a certain prefix is
currently hosted in "object-name.c". This logic reaches into specifics
of the loose object source, so it breaks once a different backend is
used for the object storage.
Move the logic to iterate through loose objects with a prefix into
"object-file.c". This is done by extending the for-each-object options
to support an optional prefix that is then honored by the loose source.
Naturally, we'll also have this support in the packfile store. This is
done in the next commit.
Furthermore, there are no users of the loose cache outside of
"object-file.c" anymore. As such, convert `odb_source_loose_cache()` to
have file scope.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `odb_for_each_object()` function only accepts a bitset of flags. In
a subsequent commit we'll want to change object iteration to also
support iterating over only those objects that have a specific prefix.
While we could of course add the prefix to the function signature, or
alternatively introduce a new function, both of these options don't
really seem to be that sensible.
Instead, introduce a new `struct odb_for_each_object_options` that can
be passed to a new `odb_for_each_object_ext()` function. Splice through
the options structure into the respective object database sources.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
oidtree: extend iteration to allow for arbitrary return codes
The interface `cb_each()` iterates through a crit-bit tree and calls a
specific callback function for each of the contained items. The callback
function is expected to return either:
- `CB_CONTINUE` in case iteration shall continue.
- `CB_BREAK` to abort iteration.
This is needlessly restrictive though, as callers may want to return
arbitrary values and have them be bubbled up to the `cb_each()` call
site. In fact, this is a rather common pattern we have: whenever such a
callback function returns a non-zero error code, we abort iteration and
bubble up the code as-is.
Refactor both the crit-bit tree and oidtree subsystems to behave
accordingly.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "oidtree.c" subsystem is rather small and self-contained and tends
to just work. It thus doesn't typically receive a lot of attention,
which has as a consequence that it's coding style is somewhat dated
nowadays.
Modernize the style of this subsystem a bit:
- Rename the `oidtree_iter()` function to `oidtree_each_cb()`.
- Rename `struct oidtree_iter_data` to `struct oidtree_each_data` to
match the renamed callback function type.
- Rename parameters and variables to clarify their intent.
- Add comments that explain what some of the functions do.
- Adapt the return value of `oidtree_contains()` to be a boolean.
This prepares for some changes to the subsystem that'll happen in the
next commit.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
path-walk: fix NULL pointer dereference in error message
When lookup_tree() or lookup_blob() cannot find a tree entry's object,
'o' is set to NULL via:
o = child ? &child->object : NULL;
The subsequent null-check catches this correctly, but then dereferences
'o' to format the error message:
error(_("failed to find object %s"), oid_to_hex(&o->oid));
This causes a segfault instead of the intended diagnostic output.
Fix this by using &entry.oid instead. 'entry' is the struct name_entry
populated by tree_entry() on each loop iteration and holds the OID of
the failing lookup -- which is exactly what the error should report.
This crash is reachable via git-backfill(1) when a tree entry's object
is absent from the local object database.
Signed-off-by: Yuvraj Singh Chauhan <ysinghcin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Fri, 20 Mar 2026 08:23:32 +0000 (09:23 +0100)]
Merge branch 'jx/i18n-fix' of github.com:jiangxin/gitk
* 'jx/i18n-fix' of github.com:jiangxin/gitk:
gitk: l10n: make PO headers identify the Gitk project
gitk: ignore generated POT file
gitk: i18n: use "Gitk" as package name in POT file
Jeff King [Tue, 17 Mar 2026 23:02:23 +0000 (19:02 -0400)]
contrib/diff-highlight: do not highlight identical pairs
We pair lines for highlighting based on their position in the hunk. So
we should never see two identical lines paired, like:
-one
-two
+one
+something else
which would pair -one/+one, because that implies that the diff could
easily be shrunk by turning line "one" into context.
But there is (at least) one exception: removing a newline at the end of
a file will produce a diff like:
-foo
+foo
\No newline at end of file
And we will pair those two lines. As a result, we end up marking the
whole line, including the newline, as the shared prefix. And there's an
empty suffix.
The most obvious bug here is that when we try to print the highlighted
lines, we remove the trailing newline from the suffix, but do not bother
with the prefix (under the assumption that there had to be a difference
_somewhere_ in the line, and thus the prefix would not eat all the way
up to the newline). And so you get an extra line like:
-foo
+foo
\No newline at end of file
This is obviously ugly, but also causes interactive.diffFilter to
(rightly) complain that the input and output do not match their lines
1-to-1.
This could easily be fixed by chomping the prefix, too, but I think the
problem is deeper. For one, I suspect some of the other logic gets
confused by forming an array with zero-indexed element "3" in a
3-element array. But more importantly, we try not to highlight whole
lines, as there's nothing interesting to show there. So let's catch this
early in is_pair_interesting() and bail to our usual passthrough
strategy.
Reported-by: Scott Baker <scott@perturb.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jiang Xin [Thu, 19 Mar 2026 09:11:17 +0000 (17:11 +0800)]
gitk: l10n: make PO headers identify the Gitk project
Commit f697d08 (gitk: i18n: use "Gitk" as package name in POT file,
2026-03-19) updated the generated POT template to use "Gitk" in its
Project-Id-Version header. Several existing PO files still carry older
header values such as "git" or "git-gui", so they do not consistently
identify themselves as Gitk translations.
Update the Project-Id-Version field in all Gitk PO files so that they
identify the Gitk project consistently.
The "Project-Id-Version" field in the PO header helps tools identify
which project a PO file belongs to. For example, Git's
"git-po-helper" uses it to choose project-specific checks and POT
handling rules. Without this change, some Gitk PO files are
misidentified because their headers still refer to other projects.
Junio C Hamano [Thu, 19 Mar 2026 22:39:02 +0000 (15:39 -0700)]
cocci: strbuf.buf is never NULL
We recently noticed one old code from 19 years ago protecting
against an ancient strbuf convention that the .buf member can be
NULL for an empty strbuf. As that is no longer the case in the
modern codebase, let's catch such a construct.
Jiang Xin [Thu, 19 Mar 2026 09:08:47 +0000 (17:08 +0800)]
gitk: ignore generated POT file
"po/gitk.pot" is generated from the source for translation maintenance.
Ignore it in the working tree so regenerating the template does not
introduce unnecessary noise in `git status`.
Jiang Xin [Thu, 19 Mar 2026 09:06:25 +0000 (17:06 +0800)]
gitk: i18n: use "Gitk" as package name in POT file
Use "Gitk" instead of the placeholder "PACKAGE" in the header of the
generated po/gitk.pot file. In particular, the "Project-Id-Version"
field in the header entry should be set to:
"Project-Id-Version: Gitk\n"
New PO files generated from this POT file will inherit that package
name.
René Scharfe [Thu, 19 Mar 2026 16:24:40 +0000 (17:24 +0100)]
commit-reach: simplify cleanup of remaining bitmaps in ahead_behind ()
Don't bother extracting the last few remaining prio_queue items in
order when we only want to free their associated bitmaps; just iterate
over the item array.
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 19 Mar 2026 16:54:56 +0000 (09:54 -0700)]
Merge branch 'ps/unit-test-c-escape-names.txt'
The unit test helper function was taught to use backslash +
mnemonic notation for certain control characters like "\t", instead
of octal notation like "\011".
Junio C Hamano [Thu, 19 Mar 2026 07:15:59 +0000 (00:15 -0700)]
rerere: update to modern representation of empty strbufs
Back when b4833a2c (rerere: Fix use of an empty strbuf.buf,
2007-09-26) was written, a freshly initialized empty strbuf
had NULL in its .buf member, with .len set to 0. The code this
patch touches in rerere.c was written to _fix_ the original code
that assumed that the .buf member is always pointing at a NUL-terminated
string, even for an empty string, which did not hold back then.
That changed in b315c5c0 (strbuf change: be sure ->buf is never ever
NULL., 2007-09-27), and it has again become safe to assume that .buf
is never NULL, and .buf[0] has '\0' for an empty string (i.e., a
strbuf with its .len member set to 0).
A funny thing is, this piece of code has been moved around from
builtin-rerere.c to rerere.c and also adjusted for updates to the
hash function API over the years, but nobody bothered to question
if this special casing for an empty strbuf was still necessary:
b4833a2c62 (rerere: Fix use of an empty strbuf.buf, 2007-09-26) 5b2fd95606 (rerere: Separate libgit and builtin functions, 2008-07-09) 9126f0091f (fix openssl headers conflicting with custom SHA1 implementations, 2008-10-01) c0f16f8e14 (rerere: factor out handle_conflict function, 2018-08-05) 0d7c419a94 (rerere: convert to use the_hash_algo, 2018-10-15) 0578f1e66a (global: adapt callers to use generic hash context helpers, 2025-01-31)
Finally get rid of the special casing that was unnecessary for the
last 19 years.
Every compilation unit in Git is expected to include "git-compat-util.h"
first, either directly or indirectly via "builtin.h". This header papers
over differences between platforms so that we can expect the typical
POSIX functions to exist. Furthermore, it provides functionality that we
end up using everywhere.
This header is thus quite heavy as a consequence. Preprocessing it as a
standalone unit via `clang -E git-compat-util.h` yields over 23,000
lines of code overall. Naturally, it takes quite some time to compile
all of this.
Luckily, this is exactly the kind of use case that precompiled headers
aim to solve: instead of recompiling it every single time, we compile it
once and then link the result into the executable. If include guards are
set up properly it means that the file won't need to be reprocessed.
Set up such a precompiled header for "git-compat-util.h" and wire it up
via Meson. This causes Meson to implicitly include the precompiled
header in all compilation units. With GCC and Clang for example this is
done via the "-include" statement [1].
This leads to a significant speedup when performing full builds:
Benchmark 1: ninja (rev = HEAD~)
Time (mean ± σ): 14.467 s ± 0.126 s [User: 248.133 s, System: 31.298 s]
Range (min … max): 14.195 s … 14.633 s 10 runs
Benchmark 2: ninja (rev = HEAD)
Time (mean ± σ): 10.307 s ± 0.111 s [User: 173.290 s, System: 23.998 s]
Range (min … max): 10.030 s … 10.433 s 10 runs
Summary
ninja (rev = HEAD) ran
1.40 ± 0.02 times faster than ninja (rev = HEAD~)
In the next commit we're about to introduce a precompiled header for
"git-compat-util.h". The consequence of this change is that we'll
implicitly include that header for every compilation unit that uses the
precompiled headers.
This is okay for our "normal" library sources and our builtins. But some
of our compatibility sources do not include the header on purpose, and
doing so would cause compilation errors.
Prepare for this change by splitting out compatibility sources into
their static library. Like this, we can selectively enable precompiled
headers for the library sources.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-compat-util.h: move warning infra to prepare for PCHs
The "git-compat-util.h" header is supposed to be the first header
included by every code compilation unit. As such, a subsequent commit
will start to precompile this header to speed up compilation of Git.
This will cause an issue though with the way that we have set up the
"-Wsign-compare" warnings. It is expected that any compilation unit that
fails with that compiler warning sets `DISABLE_SIGN_COMPARE_WARNINGS`
before including "git-compat-util.h". If so, we'll disable the warning
right away via a compiler pragma.
But with precompiled headers we do not know ahead of time whether the
code unit wants to disable those warnings, and thus we'll have to
precompile the header without defining `DISABLE_SIGN_COMPARE_WARNINGS`.
But as the pragma statement is wrapped by our include guards, the second
include of that file will not have the desired effect of disabling the
warnings anymore.
We could fix this issue by declaring a new macro that compilation units
are expected to invoke after having included the file. In retrospect,
that would have been the better way to handle this as it allows for
more flexibility: we could for example toggle the warning for specific
code blocks, only. But changing this now would require a bunch of
changes, and the churn feels excessive for what we gain.
Instead, prepare for the precompiled headers by moving the code outside
of the include guards.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a bunch of scripts used by our different build systems that are
all located in the top-level directory. Now that we have introduced the
new "tools/" directory though we have a better home for them.
Move the scripts into the "tools/" directory.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib: move "update-unicode.sh" script into "tools/"
The "update-unicode.sh" script is used to update the unicode data
compiled into Git whenever a new version of the Unicode standard has
been released. As such, it is a natural part of our developer-facing
tooling, and its presence in "contrib/" is misleading.
Promote the script into the new "tools/" directory.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib: move "coverage-diff.sh" script into "tools/"
The "coverage-diff.sh" script can be used to get information about test
coverage fro the Git codebase. It is thus rather specific to our build
and test infrastructure and part of the developer-facing tooling. The
fact that this script is part of "contrib/" is thus rather misleading
and a historic wart.
Promote the tool into the new "tools/" directory.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib: move "coccinelle/" directory into "tools/"
The Coccinelle tool is an ingrained part of our build infrastructure. It
is executed by our CI to detect antipatterns and is used to detect
misuses of certain interfaces. It's presence in "contrib/" is thus
rather misleading.
Promote the configuration into the new "tools/" directory.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to its readme, the "contrib/" directory's main intent is to
collect stuff that is not an official part of Git, either because it is
too specialized or because it is still considered experimental. The
reality tells a bit of a different story though: while it _does_ contain
such things, it also contains other things:
- Our credential helpers, which are being distributed by many
packagers nowadays and which can be considered "stable".
- A bunch of tooling that relates to our build and test
infrastructure.
Especially the second category is somewhat of a sore spot. You really
wouldn't expect build-related tooling to be considered an optional part
of Git. Quite the opposite.
Create a new top-level "tools/" directory to fix this discrepancy. This
directory will contain all kind of tools that are related to our build
infrastructure and that Git developers are likely to use day to day.
For now, this directory doesn't contain anything yet except for a
readme and a Meson skeleton. This will change in subsequent commits.
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aditya [Wed, 18 Mar 2026 20:07:35 +0000 (20:07 +0000)]
t2107: modernize path existence check
Replace '! test -f' with 'test_path_is_missing' to get better
debugging information by reporting loudly what expectation was
not met when the assertion fails.
Signed-off-by: Aditya <adityabnw07@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jialong Wang [Wed, 18 Mar 2026 19:09:42 +0000 (15:09 -0400)]
object-name: turn INTERPRET_BRANCH_* constants into enum values
Replace the INTERPRET_BRANCH_* preprocessor constants with enum
values and use that type where these flags are stored or passed
around.
These flags describe which kinds of branches may be considered during
branch-name interpretation, so represent them as an enum describing
branch kinds while keeping the existing bitmask semantics and
INTERPRET_BRANCH_* element names.
Signed-off-by: Jialong Wang <jerrywang183@yahoo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mathias Rav [Wed, 11 Mar 2026 06:44:06 +0000 (06:44 +0000)]
merge-file: fix BUG when --object-id is used in a worktree
The `--object-id` option was added in commit e1068f0ad4
(merge-file: add an option to process object IDs, 2023-11-01)
together with a call to setup_git_directory() to avoid crashing
when run outside a repository.
However, the call to setup_git_directory() is redundant when run inside
a repository, as merge-file runs with RUN_SETUP_GENTLY, so the
repository has already been set up. The redundant call is harmless
when linked worktrees are not used, but in a linked worktree,
the repo_set_gitdir() function ends up being called twice.
Calling repo_set_gitdir() used to be silently accepted, but commit 2816b748e5 (odb: handle changing a repository's commondir, 2025-11-19)
changed this to a BUG in repository.c with the error message:
"cannot reinitialize an already-initialized object directory".
Guard the redundant call to setup_git_directory() behind a repo pointer
check, to ensure that we continue to give the correct "not a git repo"
error whilst avoiding the BUG when running in a linked worktree.
Signed-off-by: Mathias Rav <m@git.strova.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Tue, 17 Mar 2026 21:40:07 +0000 (22:40 +0100)]
use commit_stack instead of prio_queue in LIFO mode
A prio_queue with a NULL compare function acts as a stack -- the last
element in is the first one out (LIFO). Use an actual commit_stack
instead where possible, as it documents the behavior better, provides
type safety and saves some memory because prio_queue stores an
additional tie-breaking counter per element.
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 17 Mar 2026 18:01:38 +0000 (11:01 -0700)]
apply: fix new-style empty context line triggering incomplete-line check
A new-style unified context diff represents an empty context line
with an empty line (instead of a line with a single SP on it). The
code to check whitespace errors in an incoming patch is designed to
omit the first byte of a line (typically SP, "-", or "+") and pass the
remainder of the line to the whitespace checker.
Usually we do not pass a context line to the whitespace error checker,
but when we are correcting errors, we do. This "remove the first
byte and send the remainder" strategy of checking a line ended up
sending a zero-length string to the whitespace checker when seeing a
new-style empty context line, which caused the whitespace checker to
say "ah, you do not even have a newline at the end!", leading to an
"incomplete line" in the middle of the patch!
Fix this by pretending that we got a traditional empty context line
when we drive the whitespace checker.
Jialong Wang [Tue, 17 Mar 2026 16:23:21 +0000 (12:23 -0400)]
apply: report input location in binary and garbage patch errors
Several binary parsing paths in apply.c still report only line
numbers. When more than one patch input is fed to a single
invocation, that does not tell the user which input the line belongs
to.
Report the patch input location for corrupt and unrecognized binary
patches, as well as the "patch with only garbage" case, and update
the related tests.
Signed-off-by: Jialong Wang <jerrywang183@yahoo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jialong Wang [Tue, 17 Mar 2026 16:23:20 +0000 (12:23 -0400)]
apply: report input location in header parsing errors
Several header parsing errors in apply.c still report only line
numbers. When applying more than one input, that does not tell the
user which input the line belongs to.
Report the patch input location for these header parsing errors, and
update the related tests.
While touching parse_git_diff_header(), update the helper state to use
the current header line when reporting these errors.
Signed-off-by: Jialong Wang <jerrywang183@yahoo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
add-patch: use repository instance from add_i_state instead of the_repository
Functions parse_diff(), edit_hunk_manually() and patch_update_file() use
the_repository even though a repository instance is already available via
struct add_i_state s which is defined in struct add_p_state *s.
Use 's->s.r' instead of the_repository to avoid relying on global state. All
callers pass a valid add_p_state and this does not change any behavior.
This aligns with the ongoing effort to reduce usage of the_repository global
state.
Signed-off-by: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / thirdparty / git.git / log
