more than one main upstream tarballs listed.
There is 1 open security issue in buster.
commit d577dd92dac72614e108d090cd61fac1c7cf369a
Merge: 5e35e8f6ee d7922e98fa
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun Jun 16 16:17:02 2024 +0000
Merge branch 'debian-sid' into debian-experimental
* debian-sid:
debian: new upstream point release
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Change-Id: I658425b7f3a7c6a9ad49fc6546bebcbbb9afbf34
commit 5e35e8f6eed7621313c2c8a92244035f6a488119
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun Jun 16 16:13:03 2024 +0000
debian: new "next" snapshot
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Change-Id: I3d3d996bf24548fa75dba622e0b8c3693e8740ad
commit 292823351a3115061393f1e799cc038349e61979
Merge: 82386ce8b7 447d99e1c3
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun Jun 16 15:51:14 2024 +0000
Merge branch 'next' of https://kernel.googlesource.com/pub/scm/git/git into debian-experimental
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Change-Id: Ibe9be166caf3a65f2a3c38579b68a205aadfcd36
commit d7922e98fad107e82e2b11c7defecf9f6d89bfb4
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun Jun 16 15:48:22 2024 +0000
debian: new upstream point release
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
commit c2645176d92fe7e3433448bd4e1aa6e2b70a0052
Merge: 8d1426afa2 bea9ecd24b
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun Jun 16 15:39:06 2024 +0000
Merge tag 'v2.45.2' into debian-sid
Git 2.45.2
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
commit 447d99e1c3bfb5c45d0d491c7e2c0b75dd7eccf9
Merge: b56b59d1d7 a83e21de6b
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 14 14:26:35 2024 -0700
Merge branch 'tb/pseudo-merge-reachability-bitmap' into next
The pseudo-merge reachability bitmap to help more efficient storage
of the reachability bitmap in a repository with too many refs has
been added.
* tb/pseudo-merge-reachability-bitmap:
pack-bitmap.c: ensure pseudo-merge offset reads are bounded
Documentation/technical/bitmap-format.txt: add missing position table
commit a83e21de6b7630c1cdf3298d68b120dd9eaecd0f
Author: Taylor Blau <me@ttaylorr.com>
Date: Fri Jun 14 15:23:58 2024 -0400
pack-bitmap.c: ensure pseudo-merge offset reads are bounded
After reading the pseudo-merge extension's metadata table, we allocate
an array to store information about each pseudo-merge, including its
byte offset within the .bitmap file itself.
This is done like so:
pseudo_merge_ofs = index_end - 24 -
(index->pseudo_merges.nr * sizeof(uint64_t));
for (i = 0; i < index->pseudo_merges.nr; i++) {
index->pseudo_merges.v[i].at = get_be64(pseudo_merge_ofs);
pseudo_merge_ofs += sizeof(uint64_t);
}
But if the pseudo-merge table is corrupt, we'll keep calling get_be64()
past the end of the pseudo-merge extension, potentially reading off the
end of the mmap'd region.
Prevent this by ensuring that we have at least `table_size - 24` many
bytes available to read (adding 24 to the left-hand side of our
inequality to account for the length of the metadata component).
This is sufficient to prevent us from reading off the end of the
pseudo-merge extension, and ensures that all of the get_be64() calls
below are in bounds.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 20c49432e44f1c98e37f5df97c8137ecd8c1af77
Author: Taylor Blau <me@ttaylorr.com>
Date: Fri Jun 14 15:23:55 2024 -0400
Documentation/technical/bitmap-format.txt: add missing position table
While investigating a benign Coverity warning on the new pseudo-merge
implementation, I was struggling to understand the (paraphrased) below:
ofs = index_end - 24 - (index->pseudo_merges.nr * sizeof(uint64_t));
for (i = 0; i < index->pseudo_merges.nr; i++) {
index->pseudo_merges.v[i].at = get_be64(ofs);
ofs += sizeof(uint64_t);
}
, in pack-bitmap.c::load_bitmap_header(). Looking at the documentation,
the diagram describing the on-disk format (prior to this patch)
suggested that the optional extended lookup table immediately preceded
the trailing metadata portion.
If that were the case, that would make the above code from
load_bitmap_header() incorrect, as we'd be blindly reading into the
extended offset table.
But later on in the documentation there is a description of the
pseudo-merge position table as immediately preceding the trailing
metadata portion of the extension. And indeed, we do write the position
table in pack-bitmap-write.c:
/* write positions for all pseudo merges */
for (i = 0; i < writer->pseudo_merges_nr; i++)
hashwrite_be64(f, pseudo_merge_ofs[i]);
hashwrite_be32(f, writer->pseudo_merges_nr);
hashwrite_be32(f, kh_size(writer->pseudo_merge_commits));
hashwrite_be64(f, table_start - start);
hashwrite_be64(f, hashfile_total(f) - start + sizeof(uint64_t));
So this is purely a case of the diagram being out of sync with the
textual description and actual implementation of the format
specification.
Add the missing component back to the format diagram to avoid further
confusion in this area.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 82386ce8b7228291368c91334a4f3d039580dfad
Author: Emily Shaffer <nasamuffin@google.com>
Date: Fri Jun 14 12:17:33 2024 -0700
debian: new "next" snapshot
Change-Id: If3f499908e0473b3583fffa2c3da29bf828e1a81
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
commit 12498e8133335b2d4fb2cf1b205b441c57572479
Merge: cc8e2286ed dbec12cfda
Author: Emily Shaffer <nasamuffin@google.com>
Date: Fri Jun 14 12:17:01 2024 -0700
Merge branch 'next' into debian-experimental
Change-Id: Id31b941f74b5561bdb666ab4be0b4ebc9036b736
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
commit b56b59d1d7f36ee78f5a21827b57692599d09709
Merge: 8089bf6f81 607c3d372e
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 14 12:06:35 2024 -0700
Merge branch 'jc/heads-are-branches' into next
The "--heads" option of "ls-remote" and "show-ref" has been been
deprecated; "--branches" replaces "--heads".
* jc/heads-are-branches:
show-ref: introduce --branches and deprecate --heads
ls-remote: introduce --branches and deprecate --heads
refs: call branches branches
commit 8089bf6f81f292de785341487e470f6442e4c1af
Merge: dbec12cfda 028bb23a61
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 14 12:06:34 2024 -0700
Merge branch 'ps/document-breaking-changes' into next
The structure of the document that records longer-term project
decisions to deprecate/remove/update various behaviour has been
outlined.
* ps/document-breaking-changes:
BreakingChanges: document that we do not plan to deprecate git-checkout
BreakingChanges: document removal of grafting
BreakingChanges: document upcoming change from "sha1" to "sha256"
docs: introduce document to announce breaking changes
commit 028bb23a61653dde0481671a2ac4a4e83ce061b8
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 14 08:42:48 2024 +0200
BreakingChanges: document that we do not plan to deprecate git-checkout
The git-checkout(1) command is seen by many as hard to understand
because it connects two somewhat unrelated features: switching between
branches and restoring worktree files from arbitrary revisions. In 2019,
we thus implemented two new commands git-switch(1) and git-restore(1) to
split out these separate concerns into standalone functions.
This "replacement" of git-checkout(1) has repeatedly triggered concerns
for our userbase that git-checkout(1) will eventually go away. This is
not the case though: the use of that command is still widespread, and it
is not expected that this will change anytime soon.
Document that all three commands will remain for the foreseeable future.
This decision may be revisited in case we ever figure out that most
everyone has given up on any of the commands.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit fcf0f4801d9f007a3bc4358f8e2589247be81ab0
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 14 08:42:44 2024 +0200
BreakingChanges: document removal of grafting
The grafting mechanism for objects has been deprecated in e650d0643b
(docs: mark info/grafts as outdated, 2014-03-05), which is more than a
decade ago. The mechanism can lead to hard-to-debug issues and has a
superior replacement with replace refs.
Follow through with the deprecation and mark grafts for removal in Git
3.0.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 6ccf041d1d73d69d05118f739c80f83c86caf0d6
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 14 08:42:39 2024 +0200
BreakingChanges: document upcoming change from "sha1" to "sha256"
Starting with 8e42eb0e9a (doc: sha256 is no longer experimental,
2023-07-31), the "sha256" object format is no longer considered to be
experimental. Furthermore, the SHA-1 hash function is actively
recommended against by for example NIST and FIPS 140-2, and attacks
against it are becoming more practical both due to new weaknesses
(SHAppening, SHAttered, Shambles) and due to the ever-increasing
computing power. It is only a matter of time before it can be considered
to be broken completely.
Let's plan for this event by being active instead of waiting for it to
happend and announce that the default object format is going to change
from "sha1" to "sha256" with Git 3.0.
All major Git implementations (libgit2, JGit, go-git) support the
"sha256" object format and are thus prepared for this change. The most
important missing piece in the puzzle is support in forges. But while
GitLab recently gained experimental support for the "sha256" object
format though, to the best of my knowledge GitHub doesn't support it
yet. Ideally, announcing this upcoming change will encourage forges to
start building that support.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 57ec9254eb996080c757708a7eec8d3657897222
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 14 08:42:34 2024 +0200
docs: introduce document to announce breaking changes
Over time, Git has grown quite a lot. With this evolution, many ideas
that were sensible at the time they were introduced are not anymore and
are thus considered to be deprecated. And while some deprecations may be
noted in manpages, most of them are actually deprecated in the "hive
mind" of the Git community, only.
Introduce a new document that tracks such breaking changes, but also
deprecations which we are not willing to go through with, to address
this issue. This document serves multiple purposes:
- It is a way to facilitate discussion around proposed deprecations.
- It allows users to learn about deprecations and speak up in case
they have good reasons why a certain feature should not be
deprecated.
- It states intent and documents where the Git project wants to go,
both in the case where we want to deprecate, but also in the case
where we don't want to deprecate a specific feature.
The document is _not_ intended to cast every single discussion into
stone. It is supposed to be a living document that may change over time
when there are good reasons for it to change.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit dbec12cfdaf20165dabbe15855bf843922bc7aec
Merge: df378ec81e 4c063c82e9
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:57 2024 -0700
Merge branch 'pw/rebase-i-error-message' into next
When the user adds to "git rebase -i" instruction to "pick" a merge
commit, the error experience is not pleasant. Such an error is now
caught earlier in the process that parses the todo list.
* pw/rebase-i-error-message:
rebase -i: improve error message when picking merge
rebase -i: pass struct replay_opts to parse_insn_line()
commit df378ec81eecd97ac303243025221914894b0ec3
Merge: e5d17f7da2 f1160393c1
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:56 2024 -0700
Merge branch 'ds/ahead-behind-fix' into next
Fix for a progress bar.
* ds/ahead-behind-fix:
commit-graph: increment progress indicator
commit e5d17f7da23d4c168d67e6e178d1b08daf0c41ee
Merge: 3fad4afcfd 037df60013
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:55 2024 -0700
Merge branch 'ps/abbrev-length-before-setup-fix' into next
Setting core.abbrev too early before the repository set-up
(typically in "git clone") caused segfault, which as been
corrected.
* ps/abbrev-length-before-setup-fix:
object-name: don't try to abbreviate to lengths greater than hexsz
parse-options-cb: stop clamping "--abbrev=" to hash length
config: fix segfault when parsing "core.abbrev" without repo
commit 3fad4afcfd64c0fab4de2f5093f15b0685ec4eac
Merge: 5cf8d7513e f96c385449
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:54 2024 -0700
Merge branch 'rj/format-patch-auto-cover-with-interdiff' into next
"git format-patch --interdiff" for multi-patch series learned to
turn on cover letters automatically (unless told never to enable
cover letter with "--no-cover-letter" and such).
* rj/format-patch-auto-cover-with-interdiff:
format-patch: assume --cover-letter for diff in multi-patch series
t4014: cleanups in a few tests
commit 5cf8d7513ef680b60d297ce2036ed4468a566f12
Merge: eb3700b002 7dd4051b01
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:53 2024 -0700
Merge branch 'kn/update-ref-symref' into next
"git update-ref --stdin" learned to handle transactional updates of
symbolic-refs.
* kn/update-ref-symref:
update-ref: add support for 'symref-update' command
reftable: pick either 'oid' or 'target' for new updates
update-ref: add support for 'symref-create' command
update-ref: add support for 'symref-delete' command
update-ref: add support for 'symref-verify' command
refs: specify error for regular refs with `old_target`
refs: create and use `ref_update_expects_existing_old_ref()`
commit eb3700b002cbf1421c8e4818d5297243913841d2
Merge: 1cd0259667 ed54840872
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:51 2024 -0700
Merge branch 'gt/unit-test-oidtree' into next
"oidtree" tests were rewritten to use the unit test framework.
* gt/unit-test-oidtree:
t/: migrate helper/test-oidtree.c to unit-tests/t-oidtree.c
commit 1cd02596674a7fc08d2c6c3c7c8537a5944a5cf3
Merge: 1570129ebf e162aed591
Author: Junio C Hamano <gitster@pobox.com>
Date: Thu Jun 13 13:03:51 2024 -0700
Merge branch 'tb/multi-pack-reuse-fix' into next
Assorted fixes to multi-pack-index code paths.
* tb/multi-pack-reuse-fix:
pack-revindex.c: guard against out-of-bounds pack lookups
pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse
midx-write.c: do not read existing MIDX with `packs_to_include`
commit 1570129ebf8726037c796002ceeec929c386d5a6
Merge: d57b04bf16 d63586cb31
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 14:18:54 2024 -0700
Sync with 'master'
commit d57b04bf16a69ee810fe3cb5caa135669146216d
Merge: 9ce495b6cc 1d969afb78
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 14:18:38 2024 -0700
Merge branch 'ps/make-append-to-cflags' into next
To help developers, the build procedure now allows builders to use
CFLAGS_APPEND to specify additional CFLAGS.
* ps/make-append-to-cflags:
Makefile: add ability to append to CFLAGS and LDFLAGS
commit 9ce495b6ccdc7240699bf2219f18d63f433d997e
Merge: cf3de70246 d7b97b7185
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 14:18:37 2024 -0700
Merge branch 'rs/diff-exit-code-with-external-diff' into next
"git diff --exit-code --ext-diff" learned to take the exit status
of the external diff driver into account when deciding the exit
status of the overall "git diff" invocation when configured to do
so.
* rs/diff-exit-code-with-external-diff:
diff: let external diffs report that changes are uninteresting
userdiff: add and use struct external_diff
t4020: test exit code with external diffs
commit cf3de70246e5abb0c0d1ee37e01714826c5cdb80
Merge: 9958540878 e83055ecb0
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 14:18:36 2024 -0700
Merge branch 'ds/doc-add-interactive-singlekey' into next
Doc update.
* ds/doc-add-interactive-singlekey:
doc: interactive.singleKey is disabled by default
commit f1160393c172da29d0d0874c7d69ce76dbdc8c0c
Author: Derrick Stolee <stolee@gmail.com>
Date: Tue Jun 11 15:09:15 2024 +0000
commit-graph: increment progress indicator
This fixes a bug that was introduced by 368d19b0b7 (commit-graph:
refactor compute_topological_levels(), 2023-03-20): Previously, the
progress indicator was updated from `i + 1` where `i` is the loop
variable of the enclosing `for` loop. After this patch, the update used
`info->progress_cnt + 1` instead, however, unlike `i`, the
`progress_cnt` attribute was not incremented. Let's increment it.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jc: squashed in a test update from Patrick Steinhardt]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit d63586cb314731c851f28e14fc8012988467e2da
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:36:28 2024 -0700
The thirteenth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 2a061a62e28003898cb2c19ee332147b55fe95d3
Merge: 51ea70c18a 456b4dce4c
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:18 2024 -0700
Merge branch 'gt/decorate-unit-test'
A test helper that essentially is unit tests on the "decorate"
logic has been rewritten using the unit-tests framework.
* gt/decorate-unit-test:
t/: migrate helper/test-example-decorate to the unit testing framework
commit 51ea70c18ad4646fdcccdce72a1a457f7ada6297
Merge: c2f79440ac 6d107751b2
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:17 2024 -0700
Merge branch 'jk/sparse-leakfix'
Many memory leaks in the sparse-checkout code paths have been
plugged.
* jk/sparse-leakfix:
sparse-checkout: free duplicate hashmap entries
sparse-checkout: free string list after displaying
sparse-checkout: free pattern list in sparse_checkout_list()
sparse-checkout: free sparse_filename after use
sparse-checkout: refactor temporary sparse_checkout_patterns
sparse-checkout: always free "line" strbuf after reading input
sparse-checkout: reuse --stdin buffer when reading patterns
dir.c: always copy input to add_pattern()
dir.c: free removed sparse-pattern hashmap entries
sparse-checkout: clear patterns when init() sees existing sparse file
dir.c: free strings in sparse cone pattern hashmaps
sparse-checkout: pass string literals directly to add_pattern()
sparse-checkout: free string list in write_cone_to_file()
commit c2f79440acc0d24e5a8a61648cf92055cf4ca5c8
Merge: b8bdb2f283 e7c3d1ddba
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:16 2024 -0700
Merge branch 'jk/cap-exclude-file-size'
An overly large ".gitignore" files are now rejected silently.
* jk/cap-exclude-file-size:
dir.c: reduce max pattern file size to 100MB
dir.c: skip .gitignore, etc larger than INT_MAX
commit b8bdb2f2835c9877120651cc9f22eaca6f8f66a8
Merge: 22cf18fd9e 313eec177a
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:16 2024 -0700
Merge branch 'jc/safe-directory-leading-path'
The safe.directory configuration knob has been updated to
optionally allow leading path matches.
* jc/safe-directory-leading-path:
safe.directory: allow "lead/ing/path/*" match
commit 22cf18fd9ede79bdfe5ac93e09986a64052e5781
Merge: 56346ba24e 2794932548
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:15 2024 -0700
Merge branch 'gt/t-hash-unit-test'
A pair of test helpers that essentially are unit tests on hash
algorithms have been rewritten using the unit-tests framework.
* gt/t-hash-unit-test:
t/: migrate helper/test-{sha1, sha256} to unit-tests/t-hash
strbuf: introduce strbuf_addstrings() to repeatedly add a string
commit 56346ba24e16274196180a859d27a8199acb6150
Merge: a39e28ace7 efa8786800
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:14 2024 -0700
Merge branch 'cp/reftable-unit-test'
Basic unit tests for reftable have been reimplemented under the
unit test framework.
* cp/reftable-unit-test:
t: improve the test-case for parse_names()
t: add test for put_be16()
t: move tests from reftable/record_test.c to the new unit test
t: move tests from reftable/stack_test.c to the new unit test
t: move reftable/basics_test.c to the unit testing framework
commit a39e28ace77686db3324d1093a92c2cfdf5a5e0b
Merge: 8d94cfb545 56f4f4a29d
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jun 12 13:37:13 2024 -0700
Merge branch 'jc/t1517-more'
A new test was added to ensure git commands that are designed to
run outside repositories do work.
* jc/t1517-more:
imap-send: minimum leakfix
t1517: more coverage for commands that work without repository
commit ed548408723d6e969160279398cc47f88f5700bc
Author: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Date: Sat Jun 8 22:27:09 2024 +0530
t/: migrate helper/test-oidtree.c to unit-tests/t-oidtree.c
helper/test-oidtree.c along with t0069-oidtree.sh test the oidtree.h
library, which is a wrapper around crit-bit tree. Migrate them to
the unit testing framework for better debugging and runtime
performance. Along with the migration, add an extra check for
oidtree_each() test, which showcases how multiple expected matches can
be given to check_each() helper.
To achieve this, introduce a new library called 'lib-oid.h'
exclusively for the unit tests to use. It currently mainly includes
utility to generate object_id from an arbitrary hex string
(i.e. '12a' -> '12a0000000000000000000000000000000000000'). This also
handles the hash algo selection based on GIT_TEST_DEFAULT_HASH.
This library will also be helpful when we port other unit tests such
as oid-array, oidset etc.
Helped-by: Junio C Hamano <gitster@pobox.com>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
[jc: small fixlets squashed in]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 037df60013bb3f1534d4db6bf850d7547f1c1d13
Author: Patrick Steinhardt <ps@pks.im>
Date: Wed Jun 12 10:03:36 2024 +0200
object-name: don't try to abbreviate to lengths greater than hexsz
When given a length that equals the current hash algorithm's hex size,
then `repo_find_unique_abbrev_r()` exits early without trying to find an
abbreviation. This is only sensible because there is nothing to
abbreviate in the first place, so searching through objects to find a
unique prefix would be a waste of compute.
What we don't handle though is the case where the user passes a length
greater than the hash length. This is fine in practice as we still
compute the correct result. But at the very least, this is a waste of
resources as we try to abbreviate a value that cannot be abbreviated,
which causes us to hit the object database.
Start to explicitly handle values larger than hexsz to avoid this
performance penalty, which leads to a measureable speedup. The following
benchmark has been executed in linux.git:
Benchmark 1: git -c core.abbrev=9000 log --abbrev-commit (revision = HEAD~)
Time (mean ± σ): 12.812 s ± 0.040 s [User: 12.225 s, System: 0.554 s]
Range (min … max): 12.723 s … 12.857 s 10 runs
Benchmark 2: git -c core.abbrev=9000 log --abbrev-commit (revision = HEAD)
Time (mean ± σ): 11.095 s ± 0.029 s [User: 10.546 s, System: 0.521 s]
Range (min … max): 11.037 s … 11.122 s 10 runs
Summary
git -c core.abbrev=9000 log --abbrev-commit HEAD (revision = HEAD) ran
1.15 ± 0.00 times faster than git -c core.abbrev=9000 log --abbrev-commit HEAD (revision = HEAD~)
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 59ff92c516be0a2b0292acea869c6ac79f8bae5c
Author: Patrick Steinhardt <ps@pks.im>
Date: Wed Jun 12 10:03:31 2024 +0200
parse-options-cb: stop clamping "--abbrev=" to hash length
The `OPT__ABBREV()` option allows the user to specify the length that
object hashes shall be abbreviated to. This length needs to be in the
range of `(MIN_ABBREV, the_hash_algo->hexsz)`, which is why we clamp the
value as required. While this makes sense in the case of `MIN_ABBREV`,
it is unnecessary for the upper boundary as the value is eventually
passed down to `repo_find_unnique_abbrev_r()`, which handles values
larger than the current hash length just fine.
In the preceding commit, we have changed parsing of the "core.abbrev"
config to stop clamping to the upper boundary. Let's do the same here so
that the code becomes simpler, we are consistent with how we treat the
"core.abbrev" config and so that we stop depending on `the_repository`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 524c0183c999c59940ce1a8712b78e4dbd87ae60
Author: Patrick Steinhardt <ps@pks.im>
Date: Wed Jun 12 10:03:23 2024 +0200
config: fix segfault when parsing "core.abbrev" without repo
The "core.abbrev" config allows the user to specify the minimum length
when abbreviating object hashes. Next to the values "auto" and "no",
this config also accepts a concrete length that needs to be bigger or
equal to the minimum length and smaller or equal to the hash algorithm's
hex length. While the former condition is trivial, the latter depends on
the object format used by the current repository. It is thus a variable
upper boundary that may either be 40 (SHA-1) or 64 (SHA-256).
This has two major downsides. First, the user that specifies this config
must be aware of the object hashes that its repository use. If they want
to configure the value globally, then they cannot pick any value in the
range `[41, 64]` if they have any repository that uses SHA-1. If they
did, Git would error out when parsing the config.
Second, and more importantly, parsing "core.abbrev" crashes when outside
of a Git repository because we dereference `the_hash_algo` to figure out
its hex length. Starting with c8aed5e8da (repository: stop setting SHA1
as the default object hash, 2024-05-07) though, we stopped initializing
`the_hash_algo` outside of Git repositories.
Fix both of these issues by not making it an error anymore when the
given length exceeds the hash length. Instead, leave the abbreviated
length intact. `repo_find_unique_abbrev_r()` handles this just fine
except for a performance penalty which we will fix in a subsequent
commit.
Reported-by: Kyle Lippincott <spectral@google.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 1d969afb785a86ad9851c6e1c3253cc11f8507dd
Author: Patrick Steinhardt <ps@pks.im>
Date: Mon Jun 10 08:38:20 2024 +0200
Makefile: add ability to append to CFLAGS and LDFLAGS
There are some usecases where we may want to append CFLAGS to the
default CFLAGS set by Git. This could for example be to enable or
disable specific compiler warnings or to change the optimization level
that code is compiled with. This cannot be done without overriding the
complete CFLAGS value though and thus requires the user to redeclare the
complete defaults used by Git.
Introduce a new variable `CFLAGS_APPEND` that gets appended to the
default value of `CFLAGS`. As compiler options are last-one-wins, this
fulfills both of the usecases mentioned above. It's also common practice
across many other projects to have such a variable.
While at it, also introduce a matching `LDFLAGS_APPEND` variable. While
there isn't really any need for this variable as there are no default
`LDFLAGS`, users may expect this variable to exist, as well.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit e162aed591154612cbc646ab19808096d226fce5
Author: Taylor Blau <me@ttaylorr.com>
Date: Tue Jun 11 13:28:24 2024 -0400
pack-revindex.c: guard against out-of-bounds pack lookups
The function midx_key_to_pack_pos() is a helper function used by
midx_to_pack_pos() and midx_pair_to_pack_pos() to translate a (pack,
offset) tuple into a position into the MIDX pseudo-pack order.
Ensure that the pack ID given to midx_pair_to_pack_pos() is bounded by
the number of packs within the MIDX to prevent, for instance,
uninitialized memory from being used as a pack ID.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit ed4a1d6ae10e2c86ae8e05f485c3c6ad7e6da077
Author: Taylor Blau <me@ttaylorr.com>
Date: Tue Jun 11 13:28:20 2024 -0400
pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse
When performing multi-pack reuse, reuse_partial_packfile_from_bitmap()
is responsible for generating an array of bitmapped_pack structs from
which to perform reuse.
In the multi-pack case, we loop over the MIDXs packs and copy the result
of calling `nth_bitmapped_pack()` to construct the list of reusable
paths.
But we may also want to do pack-reuse over a single pack, either because
we only had one pack to perform reuse over (in the case of single-pack
bitmaps), or because we explicitly asked to do single pack reuse even
with a MIDX[^1].
When this is the case, the array we generate of reusable packs contains
only a single element, which is either (a) the pack attached to the
single-pack bitmap, or (b) the MIDX's preferred pack.
In 795006fff4 (pack-bitmap: gracefully handle missing BTMP chunks,
2024-04-15), we refactored the reuse_partial_packfile_from_bitmap()
function and stopped assigning the pack_int_id field when reusing only
the MIDX's preferred pack. This results in an uninitialized read down in
try_partial_reuse() like so:
==7474==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55c5cd191dde in try_partial_reuse pack-bitmap.c:1887:8
#1 0x55c5cd191dde in reuse_partial_packfile_from_bitmap_1 pack-bitmap.c:2001:8
#2 0x55c5cd191dde in reuse_partial_packfile_from_bitmap pack-bitmap.c:2105:3
#3 0x55c5cce0bd0e in get_object_list_from_bitmap builtin/pack-objects.c:4043:3
#4 0x55c5cce0bd0e in get_object_list builtin/pack-objects.c:4156:27
#5 0x55c5cce0bd0e in cmd_pack_objects builtin/pack-objects.c:4596:3
#6 0x55c5ccc8fac8 in run_builtin git.c:474:11
which happens when try_partial_reuse() tries to call
midx_pair_to_pack_pos() when it tries to reject cross-pack deltas.
Avoid the uninitialized read by ensuring that the pack_int_id field is
set in the single-pack reuse case by setting it to either the MIDX
preferred pack's pack_int_id, or '-1', in the case of single-pack
bitmaps. In the latter case, we never read the pack_int_id field, so
the choice of '-1' is intentional as a "garbage in, garbage out"
measure.
Guard against further regressions in this area by adding a test which
ensures that we do not throw out deltas from the preferred pack as
"cross-pack" due to an uninitialized pack_int_id.
[^1]: This can happen for a couple of reasons, either because the
repository is configured with 'pack.allowPackReuse=(true|single)', or
because the MIDX was generated prior to the introduction of the BTMP
chunk, which contains information necessary to perform multi-pack
reuse.
Reported-by: Kyle Lippincott <spectral@google.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 0c5a62f14bc1f8b240a2d650ccc3f1ce82e917f1
Author: Taylor Blau <me@ttaylorr.com>
Date: Tue Jun 11 13:28:17 2024 -0400
midx-write.c: do not read existing MIDX with `packs_to_include`
Commit d6a8c58675 (midx-write.c: support reading an existing MIDX with
`packs_to_include`, 2024-05-29) changed the MIDX generation machinery to
support reading from an existing MIDX when writing a new one.
Unfortunately, the rest of the MIDX generation machinery is not prepared
to deal with such a change. For instance, the function responsible for
adding to the object ID fanout table from a MIDX source
(midx_fanout_add_midx_fanout()) will gladly add objects from an existing
MIDX for some fanout level regardless of whether or not those objects
came from packs that are to be included in the subsequent MIDX write.
This results in broken pseudo-pack object order (leading to incorrect
object traversal results) and segmentation faults, like so (generated by
running the added test prior to the changes in midx-write.c):
#0 0x000055ee31393f47 in midx_pack_order (ctx=0x7ffdde205c70) at midx-write.c:590
#1 0x000055ee31395a69 in write_midx_internal (object_dir=0x55ee32570440 ".git/objects",
packs_to_include=0x7ffdde205e20, packs_to_drop=0x0, preferred_pack_name=0x0,
refs_snapshot=0x0, flags=15) at midx-write.c:1171
#2 0x000055ee31395f38 in write_midx_file_only (object_dir=0x55ee32570440 ".git/objects",
packs_to_include=0x7ffdde205e20, preferred_pack_name=0x0, refs_snapshot=0x0, flags=15)
at midx-write.c:1274
[...]
In stack frame #0, the code on midx-write.c:590 is using the new pack ID
corresponding to some object which was added from the existing MIDX.
Importantly, the pack from which that object was selected in the
existing MIDX does not appear in the new MIDX as it was excluded via
`--stdin-packs`.
In this instance, the pack in question had pack ID "1" in the existing
MIDX, but since it was excluded from the new MIDX, we never filled in
that entry in the pack_perm table, resulting in:
(gdb) p *ctx->pack_perm@2
$1 = {0, 1515870810}
Which is what causes the segfault above when we try and read:
struct pack_info *pack = &ctx->info[ctx->pack_perm[i]];
if (pack->bitmap_pos == BITMAP_POS_UNKNOWN)
pack->bitmap_pos = 0;
Fundamentally, we should be able to read information from an existing
MIDX when generating a new one. But in practice the midx-write.c code
assumes that we won't run into issues like the above with incongruent
pack IDs, and often makes those assumptions in extremely subtle and
fragile ways.
Instead, let's avoid reading from an existing MIDX altogether, and stick
with the pre-d6a8c58675 implementation. Harden against any regressions
in this area by adding a test which demonstrates these issues.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 995854087836ed4a61d3a38cc5e5fc7639b27baa
Merge: 9b8ec7b97d 8d94cfb545
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 11:02:17 2024 -0700
Sync with 'master'
commit 9b8ec7b97d990fc320f913f9e5848ac30a4dadeb
Merge: 9678851a9f e3d2364c45
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:48 2024 -0700
Merge branch 'jk/imap-send-plug-all-msgs-leak' into next
A leak in "git imap-send" that somehow escapes LSan has been
plugged.
* jk/imap-send-plug-all-msgs-leak:
imap-send: free all_msgs strbuf in "out" label
commit 9678851a9f6269150fefb1fd301fbc9a1203acbe
Merge: 4d62361bc7 d66fe0726b
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:47 2024 -0700
Merge branch 'ps/no-writable-strings' into next
Building with "-Werror -Wwrite-strings" is now supported.
* ps/no-writable-strings: (27 commits)
config.mak.dev: enable `-Wwrite-strings` warning
builtin/merge: always store allocated strings in `pull_twohead`
builtin/rebase: always store allocated string in `options.strategy`
builtin/rebase: do not assign default backend to non-constant field
imap-send: fix leaking memory in `imap_server_conf`
imap-send: drop global `imap_server_conf` variable
mailmap: always store allocated strings in mailmap blob
revision: always store allocated strings in output encoding
remote-curl: avoid assigning string constant to non-const variable
send-pack: always allocate receive status
parse-options: cast long name for OPTION_ALIAS
http: do not assign string constant to non-const field
compat/win32: fix const-correctness with string constants
pretty: add casts for decoration option pointers
object-file: make `buf` parameter of `index_mem()` a constant
object-file: mark cached object buffers as const
ident: add casts for fallback name and GECOS
entry: refactor how we remove items for delayed checkouts
line-log: always allocate the output prefix
line-log: stop assigning string constant to file parent buffer
...
commit 4d62361bc7c7487089ec72146120685ca2c123ab
Merge: a9c55c0f89 62c71ace44
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:46 2024 -0700
Merge branch 'jk/am-retry' into next
"git am" has a safety feature to prevent it from starting a new
session when there already is a session going. It reliably
triggers when a mbox is given on the command line, but it has to
rely on the tty-ness of the standard input. Add an explicit way to
opt out of this safety with a command line option.
* jk/am-retry:
test-terminal: drop stdin handling
am: add explicit "--retry" option
commit a9c55c0f8948caeb672c63c62e01dbab2ae18fb7
Merge: 81b46b6916 99c7de732e
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:45 2024 -0700
Merge branch 'jc/varargs-attributes' into next
Varargs functions that are unannotated as printf-like or execl-like
have been annotated as such.
* jc/varargs-attributes:
__attribute__: add a few missing format attributes
__attribute__: mark some functions with LAST_ARG_MUST_BE_NULL
__attribute__: remove redundant attribute declaration for git_die_config()
__attribute__: trace2_region_enter_printf() is like "printf"
commit 81b46b691623090c4ab0c0765ad3910ab4863430
Merge: 12570afc8e 25a0023f28
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:44 2024 -0700
Merge branch 'ps/ref-storage-migration' into next
Allow migrating a repository that uses the files backend for its
ref storage to use the reftable backend, with limitations.
* ps/ref-storage-migration:
builtin/refs: new command to migrate ref storage formats
refs: implement logic to migrate between ref storage formats
refs: implement removal of ref storages
worktree: don't store main worktree twice
reftable: inline `merged_table_release()`
refs/files: fix NULL pointer deref when releasing ref store
refs/files: extract function to iterate through root refs
refs/files: refactor `add_pseudoref_and_head_entries()`
refs: allow to skip creation of reflog entries
refs: pass storage format to `ref_store_init()` explicitly
refs: convert ref storage format to an enum
setup: unset ref storage when reinitializing repository version
commit 12570afc8e15a9fe6455c30e8ec6302e3dc739e7
Merge: 2d6725a946 f60fec6a16
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:43 2024 -0700
Merge branch 'ps/check-docs-fix' into next
"make check-docs" noticed problems and reported to its output but
failed to signal its findings with its exit status, which has been
corrected.
* ps/check-docs-fix:
ci/test-documentation: work around SyntaxWarning in Python 3.12
gitlab-ci: add job to run `make check-docs`
Documentation/lint-manpages: bubble up errors
Makefile: extract script to lint missing/extraneous manpages
commit 2d6725a94614b84c899943bcfce1015123a078af
Merge: 933f06b899 df651330ab
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:54:43 2024 -0700
Merge branch 'ps/ci-fix-detection-of-ubuntu-20' into next
Fix for an embarrassing typo that prevented running Python2 tests
anywhere.
* ps/ci-fix-detection-of-ubuntu-20:
ci: fix check for Ubuntu 20.04
commit 8d94cfb54504f2ec9edc7ca3eb5c29a3dd3675ae
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:30:07 2024 -0700
The twelfth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 5235e56ea59a014ffb999d2b4ce3ffa9c74ddce3
Merge: 718b50e3bf 64f8502b40
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:30:39 2024 -0700
Merge branch 'jk/leakfixes'
Memory leaks in "git mv" has been plugged.
* jk/leakfixes:
mv: replace src_dir with a strvec
mv: factor out empty src_dir removal
mv: move src_dir cleanup to end of cmd_mv()
t-strvec: mark variable-arg helper with LAST_ARG_MUST_BE_NULL
t-strvec: use va_end() to match va_start()
commit 718b50e3bf313d19073ad7c26107307b32dd8908
Merge: 1b76f06508 291ef5b61c
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jun 10 10:30:38 2024 -0700
Merge branch 'iw/trace-argv-on-alias'
The alias-expanded command lines are logged to the trace output.
* iw/trace-argv-on-alias:
run-command: show prepared command
Documentation: alias: add notes on shell expansion
Documentation: alias: rework notes into points
commit d7b97b7185521e3b9364b3abc6553df2480da173
Author: René Scharfe <l.s.r@web.de>
Date: Sun Jun 9 09:41:44 2024 +0200
diff: let external diffs report that changes are uninteresting
The options --exit-code and --quiet instruct git diff to indicate
whether it found any significant changes by exiting with code 1 if it
did and 0 if there were none. Currently this doesn't work if external
diff programs are involved, as we have no way to learn what they found.
Add that ability in the form of the new configuration options
diff.trustExitCode and diff.<driver>.trustExitCode and the environment
variable GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE. They pair with the config
options diff.external and diff.<driver>.command and the environment
variable GIT_EXTERNAL_DIFF, respectively.
The new options are off by default, keeping the old behavior. Enabling
them indicates that the external diff returns exit code 1 if it finds
significant changes and 0 if it doesn't, like diff(1).
The name of the new options is taken from the git difftool and mergetool
options of similar purpose. (There they enable passing on the exit code
of a diff tool and to infer whether a merge done by a merge tool is
successful.)
The new feature sets the diff flag diff_from_contents in
diff_setup_done() if we need the exit code and are allowed to call
external diffs. This disables the optimization that avoids calling the
program with --quiet. Add it back by skipping the call if the external
diff is not able to report empty diffs. We can only do that check after
evaluating the file-specific attributes in run_external_diff().
If we do run the external diff with --quiet, send its output to
/dev/null.
I considered checking the output of the external diff to check whether
its empty. It was added as 11be65cfa4 (diff: fix --exit-code with
external diff, 2024-05-05) and quickly reverted, as it does not work
with external diffs that do not write to stdout. There's no reason why
a graphical diff tool would even need to write anything there at all.
I also considered using a non-zero exit code for empty diffs, which
could be done without adding new configuration options. We'd need to
disable the optimization that allows git diff --quiet to skip calling
external diffs, though -- that might be quite surprising if graphical
diff programs are involved. And assigning the opposite meaning of the
exit codes compared to diff(1) and git diff --exit-code to the external
diff can cause unnecessary confusion.
Suggested-by: Phillip Wood <phillip.wood123@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 54443bbfc38d0252b31c821fea77320fcf0fe277
Author: René Scharfe <l.s.r@web.de>
Date: Sun Jun 9 09:39:08 2024 +0200
userdiff: add and use struct external_diff
Wrap the string specifying the external diff command in a new struct to
simplify adding attributes, which the next patch will do.
Make sure external_diff() still returns NULL if neither the environment
variable GIT_EXTERNAL_DIFF nor the configuration option diff.external is
set, to continue allowing its use in a boolean context.
Use a designated initializer for the default builtin userdiff driver to
adjust to the type change of the second struct member. Spelling out
only the non-zero members improves readability as a nice side-effect.
No functional change intended.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 33be6cf51acf74e623fb3c4e287f7aebbedf5c09
Author: René Scharfe <l.s.r@web.de>
Date: Sun Jun 9 09:38:24 2024 +0200
t4020: test exit code with external diffs
Add tests to check the exit code of git diff with its options --quiet
and --exit-code when using an external diff program. Currently we
cannot tell whether it found significant changes or not.
While at it, document briefly that --quiet turns off execution of
external diff programs because that behavior surprised me for a moment
while writing the tests.
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 99c7de732e1ea71804d7643dd121fdde4c181f76
Author: Junio C Hamano <gitster@pobox.com>
Date: Sat Jun 8 11:37:47 2024 -0700
__attribute__: add a few missing format attributes
A public function mem_pool_strfmt() takes printf like parameters,
but is not given an attribute as such. Also a few file-scope static
functions were missing their format attribute.
Add them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit ba744647eae1eeee3a1c2c3d3a2b331fc1075b54
Author: Junio C Hamano <gitster@pobox.com>
Date: Sat Jun 8 11:37:46 2024 -0700
__attribute__: mark some functions with LAST_ARG_MUST_BE_NULL
Some varargs functions that use NULL-terminated parameter list were
missing __attributes__ ((sentinel)) aka LAST_ARG_MUST_BE_NULL.
Add them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit f52c9a2a280e872546ed84dcea71723d9a762d9a
Author: Junio C Hamano <gitster@pobox.com>
Date: Sat Jun 8 11:37:45 2024 -0700
__attribute__: remove redundant attribute declaration for git_die_config()
The convention is to declare the function attribute to an extern
function together with its declaration in the header file, without
repeating the attribute declaration with its definition in the .c
source file (a file-scope static function declares its attribute
together with its definition in the .c file it is defined, as there
is no other place to do so).
The definition of git_die_config() in config.c did not follow the
convention and had its attribute declared with both its declaration
in the header and its definition in the .c source file.
Remove the one in the config.c to match everybody else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 89e78c7cdad1ac70d16c0ceb79b3ff95dfadd2bb
Author: Junio C Hamano <gitster@pobox.com>
Date: Sat Jun 8 11:37:44 2024 -0700
__attribute__: trace2_region_enter_printf() is like "printf"
The last part of the parameter list the function takes is like
parameters to printf. Mark it as such.
An existing call that formats a value of type size_t using "%d" was
found by the compiler with the help with this annotation; fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 933f06b899833d0dfe8031667a718c8d3c37f0d8
Merge: 394989ee78 27db485c34
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 16:08:47 2024 -0700
Merge branch 'ap/credential-clear-fix' into next
Upon expiration event, we forgot to clear in-core authentication
material other than password (whose support was added recently),
which has been corrected.
* ap/credential-clear-fix:
credential: clear expired c->credential, unify secret clearing
commit 394989ee78840533d8cfe1da5591f5db3293f8bf
Merge: 7a2c4fd464 2fa04cebfb
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 16:08:47 2024 -0700
Merge branch 'jc/format-patch-with-range-diff' into next
Move inter/range-diff output to the end of the patch when
format-patch adds it to a single patch, instead of writing it
before the patch text, to be consistent with what is done for a
cover letter for a multi-patch series.
* jc/format-patch-with-range-diff:
format-patch: move range/inter diff at the end of a single patch output
show_log: factor out interdiff/range-diff generation
commit e83055ecb0bcb9b020b0c24709e7e791b459b1ac
Author: Dragan Simic <dsimic@manjaro.org>
Date: Fri Jun 7 15:27:17 2024 -0700
doc: interactive.singleKey is disabled by default
Make it clear that the interactive.singleKey configuration option is
disabled by default, using rather subtle wording that avoids an
emphasis on the actual default value. This should eliminate any
associated doubts.
While there, touch up the remaining wording of the description a bit.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit cc8e2286ed19fa6eac4084f81eed2ba6d4c2db8f
Author: Calvin Wan <calvinwan@google.com>
Date: Fri Jun 7 21:47:25 2024 +0000
debian: new "next" snapshot
Change-Id: I8e31c7dd806b8e22f4b3ac0ddeadf0a0698635f5
Signed-off-by: Calvin Wan <calvinwan@google.com>
commit 6e195abeac0c14cbdf7e8e2fed17912764993d56
Merge: 04f9b01165 7a2c4fd464
Author: Calvin Wan <calvinwan@google.com>
Date: Fri Jun 7 21:42:43 2024 +0000
Merge branch 'next' into debian-experimental
Change-Id: I4d755150e47620da677b3f0c864b930f4012495a
Signed-off-by: Calvin Wan <calvinwan@google.com>
commit f96c3854494011ccf3862c8327dcd052a8c874fb
Author: Rubén Justo <rjusto@gmail.com>
Date: Fri Jun 7 22:55:21 2024 +0200
format-patch: assume --cover-letter for diff in multi-patch series
When we deal with a multi-patch series in git-format-patch(1), if we see
`--interdiff` or `--range-diff` but no `--cover-letter`, we return with
an error, saying:
fatal: --range-diff requires --cover-letter or single patch
or:
fatal: --interdiff requires --cover-letter or single patch
This makes sense because the cover-letter is where we place the diff
from the previous version.
However, considering that `format-patch` generates a multi-patch as
needed, let's adopt a similar "cover as necessary" approach when using
`--interdiff` or `--range-diff`.
Therefore, relax the requirement for an explicit `--cover-letter` in a
multi-patch series when the user says `--iterdiff` or `--range-diff`.
Still, if only to return the error, respect "format.coverLetter=no" and
`--no-cover-letter`.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit bc665cdab70ac2aab59575902f8b1d4abe994060
Author: Rubén Justo <rjusto@gmail.com>
Date: Fri Jun 7 22:55:10 2024 +0200
t4014: cleanups in a few tests
Arrange things we are going to create to be removed at end, and then
start creating them. That way, we will clean them up even if we fail
after creating some but before the end of the command.
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 7a2c4fd46401958fd2318772bab8a8f1d5d0b288
Merge: 958f1ca681 1b76f06508
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 11:01:14 2024 -0700
Sync with 'master'
commit 1b76f065085811104b5f4adff001956d7e5c5d1c
Merge: cd77e87115 4cac79a50e
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 10:57:23 2024 -0700
Merge branch 'tb/midx-write-cleanup'
Code clean-up around writing the .midx files.
* tb/midx-write-cleanup:
pack-bitmap.c: reimplement `midx_bitmap_filename()` with helper
midx: replace `get_midx_rev_filename()` with a generic helper
midx-write.c: support reading an existing MIDX with `packs_to_include`
midx-write.c: extract `fill_packs_from_midx()`
midx-write.c: extract `should_include_pack()`
midx-write.c: pass `start_pack` to `compute_sorted_entries()`
midx-write.c: reduce argument count for `get_sorted_entries()`
midx-write.c: tolerate `--preferred-pack` without bitmaps
commit e3d2364c45bd8350e737faa6d0e2fbe2e583b03a
Author: Jeff King <peff@peff.net>
Date: Wed Jun 5 04:35:26 2024 -0400
imap-send: free all_msgs strbuf in "out" label
We read stdin into a strbuf, but most code paths never release it,
causing a leak (albeit a minor one, as we leak only when exiting from
the main function of the program).
Commit 56f4f4a29d (imap-send: minimum leakfix, 2024-06-04) did the
minimum to plug the one instance we see in the test suite, when we read
an empty input. But it was sufficient only because aside from this noop
invocation, we don't test imap-send at all!
The right spot to free is in the "out" label, which is hit by all code
paths before leaving the function. We couldn't do that in 56f4f4a29d
because there was no unified exit path. That came separately in
3aca5f7fb0 (imap-send: fix leaking memory in `imap_server_conf`,
2024-06-04), which cleaned up many other leaks (but not this one).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit f5598fcb7ba8588c78a8ab3212e94dc84155d137
Merge: 7986451963 56f4f4a29d
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 10:32:20 2024 -0700
Merge branch 'jc/t1517-more' into jk/imap-send-plug-all-msgs-leak
* jc/t1517-more:
imap-send: minimum leakfix
t1517: more coverage for commands that work without repository
commit 79864519637f58c79d15ec5b49272c0580201af3
Merge: 6c5be97e4e d66fe0726b
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Jun 7 10:32:02 2024 -0700
Merge branch 'ps/no-writable-strings' into jk/imap-send-plug-all-msgs-leak
* ps/no-writable-strings: (46 commits)
config.mak.dev: enable `-Wwrite-strings` warning
builtin/merge: always store allocated strings in `pull_twohead`
builtin/rebase: always store allocated string in `options.strategy`
builtin/rebase: do not assign default backend to non-constant field
imap-send: fix leaking memory in `imap_server_conf`
imap-send: drop global `imap_server_conf` variable
mailmap: always store allocated strings in mailmap blob
revision: always store allocated strings in output encoding
remote-curl: avoid assigning string constant to non-const variable
send-pack: always allocate receive status
parse-options: cast long name for OPTION_ALIAS
http: do not assign string constant to non-const field
compat/win32: fix const-correctness with string constants
pretty: add casts for decoration option pointers
object-file: make `buf` parameter of `index_mem()` a constant
object-file: mark cached object buffers as const
ident: add casts for fallback name and GECOS
entry: refactor how we remove items for delayed checkouts
line-log: always allocate the output prefix
line-log: stop assigning string constant to file parent buffer
...
commit d66fe0726bfb3fb1e3665f7e64b160440007d98e
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:40 2024 +0200
config.mak.dev: enable `-Wwrite-strings` warning
Writing to string constants is undefined behaviour and must be avoided
in C. Even so, the compiler does not help us with this by default
because those constants are not in fact marked as `const`. This makes it
rather easy to accidentally assign a constant to a non-const variable or
field and then later on try to either free it or write to it.
Enable `-Wwrite-strings` to catch such mistakes. With this warning
enabled, the type of string constants is changed to `const char[]` and
will thus cause compiler warnings when being assigned to non-const
fields and variables.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 71e01a0ebd50fed1d494e1b05374ec0977437248
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:35 2024 +0200
builtin/merge: always store allocated strings in `pull_twohead`
The `pull_twohead` configuration may sometimes contain an allocated
string, and sometimes it may contain a string constant. Refactor this to
instead always store an allocated string such that we can release its
resources without risk.
While at it, manage the lifetime of other config strings, as well. Note
that we explicitly don't free `cleanup_arg` here. This is because the
variable may be assigned a string constant via command line options.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit fc066767662ead1b279a20545ff02ab17d835f34
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:31 2024 +0200
builtin/rebase: always store allocated string in `options.strategy`
The `struct rebase_options::strategy` field is a `char *`, but we do end
up assigning string constants to it in two cases:
- When being passed a `--strategy=` option via the command line.
- When being passed a strategy option via `--strategy-option=`, but
not a strategy.
This will cause warnings once we enable `-Wwrite-strings`.
Ideally, we'd just convert the field to be a `const char *`. But we also
assign to this field via the GIT_TEST_MERGE_ALGORITHM envvar, which we
have to strdup(3P) into it.
Instead, refactor the code to make sure that we only ever assign
allocated strings to this field.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 25a47ffac0c50d3bae4058e6327c7bd799240df9
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:26 2024 +0200
builtin/rebase: do not assign default backend to non-constant field
The `struct rebase_options::default_backend` field is a non-constant
string, but is being assigned a constant via `REBASE_OPTIONS_INIT`.
Fix this by using `xstrdup()` to assign the variable and introduce a new
function `rebase_options_release()` that releases memory held by the
structure, including the newly-allocated variable.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 6d1f198f346fb218e06e730bac28609aa402a648
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:22 2024 +0200
imap-send: fix leaking memory in `imap_server_conf`
We never free any of the config strings that we populate into the
`struct imap_server_conf`. Fix this by creating a common exit path where
we can free resources.
While at it, drop the unused member `imap_server_conf::name`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit cea1ff7f1fb65daaf1059bdc0e5b65e2a2e3b89b
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:17 2024 +0200
imap-send: drop global `imap_server_conf` variable
In "imap-send.c", we have a global `sturct imap_server_conf` variable
that keeps track of the configuration of the IMAP server. This variable
is being populated mostly via the Git configuration.
Refactor the code to allocate the structure on the stack instead of
having it globally. This change allows us to track its lifetime more
closely.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit c77756015e66e5fc601cfb6a368c37ef1f94285a
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:12 2024 +0200
mailmap: always store allocated strings in mailmap blob
Same as with the preceding commit, the `git_mailmap_blob` may sometimes
contain an allocated string and sometimes it may contain a string
constant. This is risky and can easily lead to bugs in case the variable
is getting re-assigned, where the code may then try to free the previous
value to avoid memory leaks.
Safeguard the code by always storing allocated strings in the variable.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 844d190677216c0754287f14d9474a55adf606a4
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:07 2024 +0200
revision: always store allocated strings in output encoding
The `git_log_output_encoding` variable can be set via the `--encoding=`
option. When doing so, we conditionally either assign it to the passed
value, or if the value is "none" we assign it the empty string.
Depending on which of the both code paths we pick though, the variable
may end up being assigned either an allocated string or a string
constant.
This is somewhat risky and may easily lead to bugs when a different code
path may want to reassign a new value to it, freeing the previous value.
We already to this when parsing the "i18n.logoutputencoding" config in
`git_default_i18n_config()`. But because the config is typically parsed
before we parse command line options this has been fine so far.
Regardless of that, safeguard the code such that the variable always
contains an allocated string. While at it, also free the old value in
case there was any to plug a potential memory leak.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit a3da6948c3b6c272bf7a381b86df9a60bdf2b052
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:39:03 2024 +0200
remote-curl: avoid assigning string constant to non-const variable
When processing remote options, we split the option line into two by
searching for a space. If there is one, we replace the space with '\0',
otherwise we implicitly assume that the value is "true" and thus assign
a string constant.
As the return value of strchr(3P) weirdly enough is a `char *` even
though it gets a `const char *` as input, the assigned-to variable also
is a non-constant. This is fine though because the argument is in fact
an allocated string, and thus we are allowed to modify it. But this will
break once we enable `-Wwrite-strings`.
Refactor the code stop splitting the fields with '\0' altogether.
Instead, we can pass the length of the option name to `set_option()` and
then use strncmp(3P) instead of strcmp(3P).
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 5bd0851d97be732470eab8cb8d7255c7050ef384
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:58 2024 +0200
send-pack: always allocate receive status
In `receive_status()`, we record the reason why ref updates have been
rejected by the remote via the `remote_status`. But while we allocate
the assigned string when a reason was given, we assign a string constant
when no reason was given.
This has been working fine so far due to two reasons:
- We don't ever free the refs in git-send-pack(1)'
- Remotes always give a reason, at least as implemented by Git proper.
Adapt the code to always allocate the receive status string and free the
refs.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit e463c5e8a0c306b62c25ff5856087ab32403158a
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:54 2024 +0200
parse-options: cast long name for OPTION_ALIAS
We assign the long name for OPTION_ALIAS options to a non-constant value
field. We know that the variable will never be written to, but this will
cause warnings once we enable `-Wwrite-strings`.
Cast away the constness to be prepared for this change.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 8d3a7ce441422f4b48f14c19a1b3be4ba7bfd30f
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:49 2024 +0200
http: do not assign string constant to non-const field
In `write_accept_language()`, we put all acceptable languages into an
array. While all entries in that array are allocated strings, the final
entry in that array is a string constant. This is fine because we
explicitly skip over the last entry when freeing the array, but will
cause warnings once we enable `-Wwrite-strings`.
Adapt the code to also allocate the final entry.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit e7b40195ae0082d04ea8c0d1769d90ea700b76f2
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:44 2024 +0200
compat/win32: fix const-correctness with string constants
Adjust various places in our Win32 compatibility layer where we are not
assigning string constants to `const char *` variables.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 9c076c32fbb15a0887a1ed4d2afa7e5a3fd74727
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:39 2024 +0200
pretty: add casts for decoration option pointers
The `struct decoration_options` have a prefix and suffix field which are
both non-constant, but we assign a constant pointer to them. This is
safe to do because we pass them to `format_decorations()`, which never
modifies these pointers, and then immediately discard the structure. Add
explicit casts to avoid compilation warnings with `-Wwrite-strings`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 9f03e4813a5b4e469b3a7f5ad4ada3a9c3f92bfd
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:35 2024 +0200
object-file: make `buf` parameter of `index_mem()` a constant
The `buf` parameter of `index_mem()` is a non-constant string. This will
break once we enable `-Wwrite-strings` because we also pass constants
from at least one callsite.
Adapt the parameter to be a constant. As we cannot free the buffer
without casting now, this also requires us to move the lifetime of the
nested buffer around.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 724b6d1e18606ca2fa14d7cc48c3bf3884363e25
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:30 2024 +0200
object-file: mark cached object buffers as const
The buffers of cached objects are never modified, but are still stored
as a non-constant pointer. This will cause a compiler warning once we
enable the `-Wwrite-strings` compiler warning as we assign an empty
constant string when initializing the static `empty_tree` cached object.
Convert the field to be constant. This requires us to shuffle around
the code a bit because we memcpy(3P) into the allocated buffer in
`pretend_object_file()`. This is easily fixed though by allocating the
buffer into a temporary variable first.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 32f9929109e2858b81403f2cbb2a80774f822859
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:25 2024 +0200
ident: add casts for fallback name and GECOS
In `xgetpwuid_self()`, we return a fallback identity when it was not
possible to look up the current identity. This fallback identity needs
to be internal and must never be written to by the calles as specified
by getpwuid(3P). As both the `pw_name` and `pw_gecos` fields are marked
as non-constant though, it will cause a warning to assign constant
strings to them once compiling with `-Wwrite-strings`.
Add explicit casts to avoid the warning.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit b31607a3e03b2002c468c16bb71fcaf2d1846e09
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:20 2024 +0200
entry: refactor how we remove items for delayed checkouts
When finalizing a delayed checkout, we sort out several strings from the
passed-in string list by first assigning the empty string to those
filters and then calling `string_list_remove_empty_items()`. Assigning
the empty string will cause compiler warnings though as the string is
a `char *` once we enable `-Wwrite-strings`.
Refactor the code to use a `NULL` pointer with `filter_string_list()`
instead to avoid this warning.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 394affd46dc9b0c805df6e999837aa297f844fc0
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:16 2024 +0200
line-log: always allocate the output prefix
The returned string by `output_prefix()` is sometimes a string constant
and sometimes an allocated string. This has been fine until now because
we always leak the allocated strings, and thus we never tried to free
the string constant.
Fix the code to always return an allocated string and free the returned
value at all callsites.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 42d2ad55566013535c16b80fc2d445da93cceed3
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:11 2024 +0200
line-log: stop assigning string constant to file parent buffer
Stop assigning a string constant to the file parent buffer and instead
assign an allocated string. While the code is fine in practice, it will
break once we compile with `-Wwrite-strings`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 86badd4d0a51262c2da1ca45c36612a28aad3b59
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:06 2024 +0200
diff: cast string constant in `fill_textconv()`
The `fill_textconv()` function is responsible for converting an input
file with a textconv driver, which is then passed to the caller. Weirdly
though, the function also handles the case where there is no textconv
driver at all. In that case, it will return either the contents of the
populated filespec, or an empty string if the filespec is invalid.
These two cases have differing memory ownership semantics. When there is
a textconv driver, then the result is an allocated string. Otherwise,
the result is either a string constant or owned by the filespec struct.
All callers are in fact aware of this weirdness and only end up freeing
the output buffer when they had a textconv driver.
Ideally, we'd split up this interface to only perform the conversion via
the textconv driver, and BUG in case the caller didn't provide one. This
would make memory ownership semantics much more straight forward. For
now though, let's simply cast the empty string constant to `char *` to
avoid a warning with `-Wwrite-strings`. This is equivalent to the same
cast that we already have in `fill_mmfile()`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 81654d27bf9e2f3745fb6190cb5b0863f91a644e
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:38:02 2024 +0200
builtin/remote: cast away constness in `get_head_names()`
In `get_head_names()`, we assign the "refs/heads/*" string constant to
`struct refspec_item::{src,dst}`, which are both non-constant pointers.
Ideally, we'd refactor the code such that both of these fields were
constant. But `struct refspec_item` is used for two different usecases
with conflicting requirements:
- To query for a source or destination based on the given refspec. The
caller either sets `src` or `dst` as the branch that we want to
search for, and the respective other field gets populated. The
fields should be constant when being used as a query parameter,
which is owned by the caller, and non-constant when being used as an
out parameter, which is owned by the refspec item. This is is
contradictory in itself already.
- To store refspec items with their respective source and destination
branches, in which case both fields should be owned by the struct.
Ideally, we'd split up this interface to clearly separate between
querying and storing, which would enable us to clarify lifetimes of the
strings. This would be a much bigger undertaking though.
Instead, accept the status quo for now and cast away the constness of
the source and destination patterns. We know that those are not being
written to or freed, so while this is ugly it certainly is fine for now.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 235ac3f81ad1950f2e6b47b30561eb96844e1c85
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:37:57 2024 +0200
refspec: remove global tag refspec structure
We have a global tag refspec structure that is used by both git-clone(1)
and git-fetch(1). Initialization of the structure will break once we
enable `-Wwrite-strings`, even though the breakage is harmless. While we
could just add casts, the structure isn't really required in the first
place as we can simply initialize the structures at the respective
callsites.
Refactor the code accordingly.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 66f892bb075f19bed784b86c7850a89c9a865aca
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:37:52 2024 +0200
reftable: cast away constness when assigning constants to records
The reftable records are used in multiple ways throughout the reftable
library. In many of those cases they merely act as input to a function
without getting modified by it at all. Most importantly, this happens
when writing records and when querying for records.
We rely on this in our tests and thus assign string constants to those
fields, which is about to generate warnings as those fields are of type
`char *`. While we could go through the process and instead allocate
those strings in all of our tests, this feels quite unnecessary.
Instead, add casts to `char *` for all of those strings. As this is part
of our tests, this also nicely serves as a demonstration that nothing
writes or frees those string constants, which would otherwise lead to
segfaults.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit 23c32511b31f2123fd194ba3a89c758ba3e55143
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:37:48 2024 +0200
refs/reftable: stop micro-optimizing refname allocations on copy
When copying refs, we execute `write_copy_table()` to write the new
table. As the names are given to us via `arg->newname` and
`arg->oldname`, respectively, we optimize away some allocations by
assigning those fields to the reftable records we are about to write
directly, without duplicating them. This requires us to cast the input
to `char *` pointers as they are in fact constant strings. Later on, we
then unset the refname for all of the records before calling
`reftable_log_record_release()` on them.
We also do this when assigning the "HEAD" constant, but here we do not
cast because its type is `char[]` by default. It's about to be turned
into `const char *` though once we enable `-Wwrite-strings` and will
thus cause another warning.
It's quite dubious whether this micro-optimization really helps. We're
about to write to disk anyway, which is going to be way slower than a
small handful of allocations. Let's drop the optimization altogther and
instead copy arguments to simplify the code and avoid the future warning
with `-Wwrite-strings`.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit c113c5df7911bf7bc6a4542131ac5bf983532a97
Author: Patrick Steinhardt <ps@pks.im>
Date: Fri Jun 7 08:37:43 2024 +0200
global: convert intentionally-leaking config strings to consts
There are multiple cases where we intentionally leak config strings:
- `struct gpg_format` is used to track programs that can be used for
signing commits, either via gpg(1), gpgsm(1) or ssh-keygen(1). The
user can override the commands via several config variables. As the
array is populated once, only, and the struct memers are never
written to or free'd.
- `struct ll_merge_driver` is used to track merge drivers. Same as
with the GPG format, these drivers are populated once and then
reused. Its data is never written to or free'd, either.
- `struct userdiff_funcname` and `struct userdiff_driver` can be
configured via `diff.<driver>.*` to add additional drivers. Again,
these have a global lifetime and are never written to or free'd.
All of these are intentionally kept alive and are never written to.
Furthermore, all of these are being assigned both string constants in
some places, and allocated strings in other places. This will cause
warnings once we enable `-Wwrite-strings`, so let's mark the respective
fields as `const char *` and cast away the constness when assigning
those values.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
![[bug history graph]](https://qa.debian.org/data/bts/graphs/g/git.png){kind=link}