summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-25commit-graph: unconditionally load Bloom filtersTaylor Blau1-4/+10
In an earlier commit, we began ignoring the Bloom data ("BDAT") chunk for commit-graphs whose Bloom filters were computed using a hash version incompatible with the value of `commitGraph.changedPathVersion`. Now that the Bloom API has been hardened to discard these incompatible filters (with the exception of low-level APIs), we can safely load these Bloom filters unconditionally. We no longer want to return early from `graph_read_bloom_data()`, and similarly do not want to set the bloom_settings' `hash_version` field as a side-effect. The latter is because we want to wait until we know which Bloom settings we're using (either the defaults, from the GIT_TEST variables, or from the previous commit-graph layer) before deciding what hash_version to use. If we detect an existing BDAT chunk, we'll infer the rest of the settings (e.g., number of hashes, bits per entry, and maximum number of changed paths) from the earlier graph layer. The hash_version will be inferred from the previous layer as well, unless one has already been specified via configuration. Once all of that is done, we normalize the value of the hash_version to either "1" or "2". Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25bloom: prepare to discard incompatible Bloom filtersTaylor Blau2-3/+37
Callers use the inline `get_bloom_filter()` implementation as a thin wrapper around `get_or_compute_bloom_filter()`. The former calls the latter with a value of "0" for `compute_if_not_present`, making `get_bloom_filter()` the default read-only path for fetching an existing Bloom filter. Callers expect the value returned from `get_bloom_filter()` is usable, that is that it's compatible with the configured value corresponding to `commitGraph.changedPathsVersion`. This is OK, since the commit-graph machinery only initializes its BDAT chunk (thereby enabling it to service Bloom filter queries) when the Bloom filter hash_version is compatible with our settings. So any value returned by `get_bloom_filter()` is trivially useable. However, subsequent commits will load the BDAT chunk even when the Bloom filters are built with incompatible hash versions. Prepare to handle this by teaching `get_bloom_filter()` to discard filters that are incompatible with the configured hash version. Callers who wish to read incompatible filters (e.g., for upgrading filters from v1 to v2) may use the lower level routine, `get_or_compute_bloom_filter()`. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25bloom: annotate filters with hash versionTaylor Blau2-3/+9
In subsequent commits, we will want to load existing Bloom filters out of a commit-graph, even when the hash version they were computed with does not match the value of `commitGraph.changedPathVersion`. In order to differentiate between the two, add a "version" field to each Bloom filter. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25repo-settings: introduce commitgraph.changedPathsVersionTaylor Blau5-8/+33
A subsequent commit will introduce another version of the changed-path filter in the commit graph file. In order to control which version to write (and read), a config variable is needed. Therefore, introduce this config variable. For forwards compatibility, teach Git to not read commit graphs when the config variable is set to an unsupported version. Because we teach Git this, commitgraph.readChangedPaths is now redundant, so deprecate it and define its behavior in terms of the config variable we introduce. This commit does not change the behavior of writing (Git writes changed path filters when explicitly instructed regardless of any config variable), but a subsequent commit will restrict Git such that it will only write when commitgraph.changedPathsVersion is a recognized value. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25bloom.h: make `load_bloom_filter_from_graph()` publicTaylor Blau2-3/+8
Prepare for a future commit to use the load_bloom_filter_from_graph() function directly to load specific Bloom filters out of the commit-graph for manual inspection (to be used during tests). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25t/helper/test-read-graph.c: extract `dump_graph_info()`Taylor Blau1-13/+18
Prepare for the 'read-graph' test helper to perform other tasks besides dumping high-level information about the commit-graph by extracting its main routine into a separate function. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25gitformat-commit-graph: describe version 2 of BDATJonathan Tan1-3/+6
The code change to Git to support version 2 will be done in subsequent commits. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25commit-graph: ensure Bloom filters are read with consistent settingsTaylor Blau2-1/+92
The changed-path Bloom filter mechanism is parameterized by a couple of variables, notably the number of bits per hash (typically "m" in Bloom filter literature) and the number of hashes themselves (typically "k"). It is critically important that filters are read with the Bloom filter settings that they were written with. Failing to do so would mean that each query is liable to compute different fingerprints, meaning that the filter itself could return a false negative. This goes against a basic assumption of using Bloom filters (that they may return false positives, but never false negatives) and can lead to incorrect results. We have some existing logic to carry forward existing Bloom filter settings from one layer to the next. In `write_commit_graph()`, we have something like: if (!(flags & COMMIT_GRAPH_NO_WRITE_BLOOM_FILTERS)) { struct commit_graph *g = ctx->r->objects->commit_graph; /* We have changed-paths already. Keep them in the next graph */ if (g && g->chunk_bloom_data) { ctx->changed_paths = 1; ctx->bloom_settings = g->bloom_filter_settings; } } , which drags forward Bloom filter settings across adjacent layers. This doesn't quite address all cases, however, since it is possible for intermediate layers to contain no Bloom filters at all. For example, suppose we have two layers in a commit-graph chain, say, {G1, G2}. If G1 contains Bloom filters, but G2 doesn't, a new G3 (whose base graph is G2) may be written with arbitrary Bloom filter settings, because we only check the immediately adjacent layer's settings for compatibility. This behavior has existed since the introduction of changed-path Bloom filters. But in practice, this is not such a big deal, since the only way up until this point to modify the Bloom filter settings at write time is with the undocumented environment variables: - GIT_TEST_BLOOM_SETTINGS_BITS_PER_ENTRY - GIT_TEST_BLOOM_SETTINGS_NUM_HASHES - GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS (it is still possible to tweak MAX_CHANGED_PATHS between layers, but this does not affect reads, so is allowed to differ across multiple graph layers). But in future commits, we will introduce another parameter to change the hash algorithm used to compute Bloom fingerprints itself. This will be exposed via a configuration setting, making this foot-gun easier to use. To prevent this potential issue, validate that all layers of a split commit-graph have compatible settings with the newest layer which contains Bloom filters. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Original-test-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25revision.c: consult Bloom filters for root commitsTaylor Blau2-6/+28
The commit-graph stores changed-path Bloom filters which represent the set of paths included in a tree-level diff between a commit's root tree and that of its parent. When a commit has no parents, the tree-diff is computed against that commit's root tree and the empty tree. In other words, every path in that commit's tree is stored in the Bloom filter (since they all appear in the diff). Consult these filters during pathspec-limited traversals in the function `rev_same_tree_as_empty()`. Doing so yields a performance improvement where we can avoid enumerating the full set of paths in a parentless commit's root tree when we know that the path(s) of interest were not listed in that commit's changed-path Bloom filter. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Original-patch-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`Taylor Blau1-1/+13
The existing implementation of test_bloom_filters_not_used() asserts that the Bloom filter sub-system has not been initialized at all, by checking for the absence of any data from it from trace2. In the following commit, it will become possible to load Bloom filters without using them (e.g., because the `commitGraph.changedPathVersion` introduced later in this series is incompatible with the hash version with which the commit-graph's Bloom filters were written). When this is the case, it's possible to initialize the Bloom filter sub-system, while still not using any Bloom filters. When this is the case, check that the data dump from the Bloom sub-system is all zeros, indicating that no filters were used. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-25pager: die when paging to non-existing commandRubén Justo2-13/+6
When trying to execute a non-existent program from GIT_PAGER, we display an error. However, we also send the complete text to the terminal and return a successful exit code. This can be confusing for the user and the displayed error could easily become obscured by a lengthy text. For example, here the error message would be very far above after sending 50 MB of text: $ GIT_PAGER=non-existent t/test-terminal.perl git log | wc -c error: cannot run non-existent: No such file or directory 50314363 Let's make the error clear by aborting the process and return an error so that the user can easily correct their mistake. This will be the result of the change: $ GIT_PAGER=non-existent t/test-terminal.perl git log | wc -c error: cannot run non-existent: No such file or directory fatal: unable to execute pager 'non-existent' 0 The behavior change we're introducing in this commit affects two tests in t7006, which is a good sign regarding test coverage and requires us to address it. The first test is 'git skips paging non-existing command'. This test comes from f7991f01f2 (t7006: clean up SIGPIPE handling in trace2 tests, 2021-11-21,) where a modification was made to a test that was originally introduced in c24b7f6736 (pager: test for exit code with and without SIGPIPE, 2021-02-02). That original test was, IMHO, in the same direction we're going in this commit. At any rate, this test obviously needs to be adjusted to check the new behavior we are introducing. Do it. The second test being affected is: 'non-existent pager doesnt cause crash', introduced in f917f57f40 (pager: fix crash when pager program doesn't exist, 2021-11-24). As its name states, it has the intention of checking that we don't introduce a regression that produces a crash when GIT_PAGER points to a nonexistent program. This test could be considered redundant nowadays, due to us already having several tests checking implicitly what a non-existent command in GIT_PAGER produces. However, let's maintain a good belt-and-suspenders strategy; adapt it to the new world. Finally, it's worth noting that we are not changing the behavior if the command specified in GIT_PAGER is a shell command. In such cases, it is: $ GIT_PAGER=:\;non-existent t/test-terminal.perl git log :;non-existent: 1: non-existent: not found died of signal 13 at t/test-terminal.perl line 33. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-24doc: fix case error of eol attribute in exampleShane Sun1-1/+1
The eol attribute only accepts "crlf" and "lf", but the example incorrectly capitalizes "crlf". References: - https://git-scm.com/docs/gitattributes#_eol - https://github.com/git/git/blob/v2.45.2/convert.c#L1278 Signed-off-by: Shane Sun <github@waterlemons2k.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-24The sixteenth batchJunio C Hamano1-0/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-24Merge branch 'kl/attr-read-attr-fromindex-msan-workaround'Junio C Hamano1-1/+2
Code clarification to avoid an appearance of using an uninitialized variable. * kl/attr-read-attr-fromindex-msan-workaround: attr: fix msan issue in read_attr_from_index
2024-06-24Merge branch 'jc/worktree-git-path'Junio C Hamano3-8/+10
Code cleanup. * jc/worktree-git-path: worktree_git_path(): move the declaration to path.h
2024-06-24Merge branch 'tb/commit-graph-use-tempfile'Junio C Hamano3-28/+43
"git update-server-info" and "git commit-graph --write" have been updated to use the tempfile API to avoid leaving cruft after failing. * tb/commit-graph-use-tempfile: server-info.c: remove temporary info files on exit commit-graph.c: remove temporary graph layers on exit
2024-06-24Merge branch 'jc/add-i-retire-usebuiltin-config'Junio C Hamano3-26/+1
For over a year, setting add.interactive.useBuiltin configuration variable did nothing but giving a "this does not do anything" warning. Finally remove it. * jc/add-i-retire-usebuiltin-config: add-i: finally retire add.interactive.useBuiltin
2024-06-24Merge branch 'jc/no-default-attr-tree-in-bare'Junio C Hamano1-3/+2
Earlier we stopped using the tree of HEAD as the default source of attributes in a bare repository, but failed to document it. This has been corrected. * jc/no-default-attr-tree-in-bare: attr.tree: HEAD:.gitattributes is no longer the default in a bare repo
2024-06-24Merge branch 'tb/precompose-getcwd'Junio C Hamano2-2/+39
We forgot to normalize the result of getcwd() to NFC on macOS where all other paths are normalized, which has been corrected. This still does not address the case where core.precomposeUnicode configuration is not defined globally. * tb/precompose-getcwd: macOS: ls-files path fails if path of workdir is NFD
2024-06-24Merge branch 'tb/pseudo-merge-reachability-bitmap'Junio C Hamano24-55/+2605
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: (26 commits) pack-bitmap.c: ensure pseudo-merge offset reads are bounded Documentation/technical/bitmap-format.txt: add missing position table t/perf: implement performance tests for pseudo-merge bitmaps pseudo-merge: implement support for finding existing merges ewah: `bitmap_equals_ewah()` pack-bitmap: extra trace2 information pack-bitmap.c: use pseudo-merges during traversal t/test-lib-functions.sh: support `--notick` in `test_commit_bulk()` pack-bitmap: implement test helpers for pseudo-merge ewah: implement `ewah_bitmap_popcount()` pseudo-merge: implement support for reading pseudo-merge commits pack-bitmap.c: read pseudo-merge extension pseudo-merge: scaffolding for reads pack-bitmap: extract `read_bitmap()` function pack-bitmap-write.c: write pseudo-merge table pseudo-merge: implement support for selecting pseudo-merge commits config: introduce `git_config_double()` pack-bitmap: make `bitmap_writer_push_bitmapped_commit()` public pack-bitmap: implement `bitmap_writer_has_bitmapped_object_id()` pack-bitmap-write: support storing pseudo-merge commits ...
2024-06-24diff: allow --color-moved with --no-ext-diffRené Scharfe2-1/+11
We ignore the option --color-moved if an external diff program is configured, presumably because its overhead is unnecessary in that case. Respect the option if we don't actually use the external diff, though. Reported-by: lolligerhans@gmx.de Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-24object-file: fix leak on conversion failureEric Wong1-1/+1
I'm not sure exactly how to trigger the leak, but it seems fairly obvious that the `content' buffer should be freed even if convert_object_file() fails. Noticed while working in this area on unrelated things. Signed-off-by: Eric Wong <e@80x24.org> Acked-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-23Merge branch 'pk/swedish-translation'Johannes Sixt1-1597/+1670
* pk/swedish-translation: git-gui: sv.po: Update Swedish translation (576t0f0u)
2024-06-23Merge branch 'bc/french-translation'Johannes Sixt1-1/+1
* bc/french-translation: git-gui: po: fix typo in French "aperçu"
2024-06-21fuzz: minimum fuzzers environment lacks libcURLJunio C Hamano1-0/+1
The "fuzz smoke test" job compiles various .o files to create libgit.a and others, but the final build product of the fuzzer build is *not* "git". Since the job is not interested in building a working "git", it does not define any build flags, and among the notable ones that are missing is NO_CURL---even though the CI environment that runs the job does not have libcURL development package installed. This obviously leads to a build failure. Pass NO_CURL=NoThanks to "make" to make sure things will build correctly, if we add any conditional compilation with "#ifdef NO_CURL ... #endif" in the codebase. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-21version: teach --build-options to reports zlib version informationRandall S. Becker1-0/+3
Show ZLIB_VERSION, if defined, in "git version --build-options" output. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-21version: teach --build-options to reports libcurl version informationRandall S. Becker1-0/+7
Show LIBCURL_VERSION, if defined, in "git version --build-options" output. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20The fifteenth batchJunio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20Merge branch 'jc/heads-are-branches'Junio C Hamano8-39/+78
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
2024-06-20Merge branch 'ps/document-breaking-changes'Junio C Hamano1-0/+135
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
2024-06-20Merge branch 'pw/rebase-i-error-message'Junio C Hamano9-30/+153
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()
2024-06-20Merge branch 'ds/ahead-behind-fix'Junio C Hamano2-2/+2
Fix for a progress bar. * ds/ahead-behind-fix: commit-graph: increment progress indicator
2024-06-20Merge branch 'ps/abbrev-length-before-setup-fix'Junio C Hamano5-5/+34
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
2024-06-20Merge branch 'rj/format-patch-auto-cover-with-interdiff'Junio C Hamano3-5/+36
"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
2024-06-20Merge branch 'kn/update-ref-symref'Junio C Hamano14-42/+836
"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()`
2024-06-20Merge branch 'gt/unit-test-oidtree'Junio C Hamano8-108/+197
"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
2024-06-20Merge branch 'tb/multi-pack-reuse-fix'Junio C Hamano5-11/+103
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`
2024-06-20Merge branch 'ps/make-append-to-cflags'Junio C Hamano1-2/+2
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
2024-06-20Merge branch 'rs/diff-exit-code-with-external-diff'Junio C Hamano8-19/+168
"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
2024-06-20Merge branch 'ds/doc-add-interactive-singlekey'Junio C Hamano1-4/+4
Doc update. * ds/doc-add-interactive-singlekey: doc: interactive.singleKey is disabled by default
2024-06-20version: --build-options reports OpenSSL version informationRandall S. Becker1-0/+3
This change uses the OpenSSL supplied OPENSSL_VERSION_TEXT #define supplied for this purpose by that project. If the #define is not present, the version is not reported. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20commit: remove find_header_mem()René Scharfe2-19/+2
cfc5cf428b (receive-pack.c: consolidate find header logic, 2022-01-06) introduced find_header_mem() and turned find_commit_header() into a thin wrapper. Since then, the latter has become the last remaining caller of the former. Remove it to restore find_commit_header() to the state before cfc5cf428b, get rid of a strlen(3) call and resolve a NEEDSWORK note in the process. Signed-off-by: René Scharfe <l.s.r@web.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20t5500: fix mistaken $SERVER reference in helper functionJeff King1-1/+1
The end of t5500 contains two tests which use a single helper function, fetch_filter_blob_limit_zero(). It takes a parameter to point to the path of the server repository, which we store locally as $SERVER. The first caller uses the relative path "server", while the second points into the httpd document root. Commit 07ef3c6604 (fetch test: use more robust test for filtered objects, 2019-12-23) refactored some lines, but accidentally switched "$SERVER" to "server" in one spot. That means the second caller is looking at the server directory from the previous test rather than its own. This happens to work out because the "server" directory from the first test is still hanging around, and the contents of the two are identical. But it was clearly not the intended behavior, and is fragile to cleaning up the leftovers from the first test. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20mingw: drop bogus (and unneeded) declaration of `_pgmptr`Johannes Schindelin1-1/+0
In 08809c09aa13 (mingw: add a helper function to attach GDB to the current process, 2020-02-13), I added a declaration that was not needed. Back then, that did not matter, but now that the declaration of that symbol was changed in mingw-w64's headers, it causes the following compile error: CC compat/mingw.o compat/mingw.c: In function 'open_in_gdb': compat/mingw.c:35:9: error: function declaration isn't a prototype [-Werror=strict-prototypes] 35 | extern char *_pgmptr; | ^~~~~~ In file included from C:/git-sdk-64/usr/src/git/build-installers/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/mm_malloc.h:27, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/xmmintrin.h:34, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/immintrin.h:31, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/x86intrin.h:32, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/include/winnt.h:1658, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/include/minwindef.h:163, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/include/windef.h:9, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/include/windows.h:69, from C:/git-sdk-64/usr/src/git/build-installers/mingw64/include/winsock2.h:23, from compat/../git-compat-util.h:215, from compat/mingw.c:1: compat/mingw.c:35:22: error: '__p__pgmptr' redeclared without dllimport attribute: previous dllimport ignored [-Werror=attributes] 35 | extern char *_pgmptr; | ^~~~~~~ Let's just drop the declaration and get rid of this compile error. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20fetch-pack: fix segfault when fscking without --lock-packJeff King2-1/+13
The fetch-pack internals have multiple options related to creating ".keep" lock-files for the received pack: - if args.lock_pack is set, then we tell index-pack to create a .keep file. In the fetch-pack plumbing command, this is triggered by passing "-k" twice. - if the caller passes in a pack_lockfiles string list, then we use it to record the path of the keep-file created by index-pack. We get that name by reading the stdout of index-pack. In the fetch-pack command, this is triggered by passing the (undocumented) --lock-pack option; without it, we pass in a NULL string list. So it's possible to ask index-pack to create the lock-file (using "-k -k") but not ask to record it (by avoiding "--lock-pack"). This worked fine until 5476e1efde (fetch-pack: print and use dangling .gitmodules, 2021-02-22), but now it causes a segfault. Before that commit, if pack_lockfiles was NULL, we wouldn't bother reading the output from index-pack at all. But since that commit, index-pack may produce extra output if we asked it to fsck. So even if nobody cares about the lockfile path, we still need to read it to skip to the output we do care about. We correctly check that we didn't get a NULL lockfile path (which can happen if we did not ask it to create a .keep file at all), but we missed the case where the lockfile path is not NULL (due to "-k -k") but the pack_lockfiles string_list is NULL (because nobody passed "--lock-pack"), and segfault trying to add to the NULL string-list. We can fix this by skipping the append to the string list when either the value or the list is NULL. In that case we must also free the lockfile path to avoid leaking it when it's non-NULL. Nobody noticed the bug for so long because the transport code used by "git fetch" always passes in a pack_lockfiles pointer, and remote-curl (the main user of the fetch-pack plumbing command) always passes --lock-pack. Reported-by: Kirill Smelkov <kirr@nexedi.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20merge-ort: convert more error() cases to path_msg()Elijah Newren2-13/+42
merge_submodule() stores errors using path_msg(), whereas other call sites make use of the error() function. This is inconsistent, and moving towards path_msg() seems more friendly for libification efforts since it will allow the caller to determine whether the error messages need to be printed. Note that this deferred handling of error messages changes the error message in a recursive merge from error: failed to execute internal merge to From inner merge: error: failed to execute internal merge which provides a little more information about the error which may be useful. Since the recursive merge strategy still only shows the older error, we had to adjust the new testcase introduced a few commits ago to just search for the older message somewhere in the output. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20merge-ort: upon merge abort, only show messages causing the abortElijah Newren1-25/+53
When something goes wrong enough that we need to abort early and not even attempt merging the remaining files, it probably does not make sense to report conflicts messages for the subset of files we processed before hitting the fatal error. Instead, only show the messages associated with paths where we hit the fatal error. Also, print these messages to stderr rather than stdout. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20merge-ort: loosen commented requirementsElijah Newren1-1/+1
The comment above type_short_descriptions claimed that the order had to match what was found in the conflict_info_and_types enum. Since type_short_descriptions uses designated initializers, the order should not actually matter; I am guessing that positional initializers may have been under consideration when that comment was added, but the comment was not updated when designated initializers were chosen. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20merge-ort: clearer propagation of failure-to-function from merge_submoduleElijah Newren1-0/+2
The 'clean' member variable is somewhat of a tri-state (1 = clean, 0 = conflicted, -1 = failure-to-determine), but we often like to think of it as binary (ignoring the possibility of a negative value) and use constructs like '!clean' to reflect this. However, these constructs can make codepaths more difficult to understand, unless we handle the negative case early and return pre-emptively; do that in handle_content_merge() to make the code a bit easier to read. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-06-20merge-ort: fix type of local 'clean' var in handle_content_merge ()Elijah Newren1-2/+3
handle_content_merge() returns an int. Every caller of handle_content_merge() expects an int. However, we declare a local variable 'clean' that we use for the return value to be unsigned. To make matters worse, we also assign 'clean' the return value of merge_submodule() in one codepath, which is defined to return an int. It seems that the only reason to have 'clean' be unsigned was to allow a cutesy bit manipulation operation to be well-defined. Fix the type of the 'clean' local in handle_content_merge(). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>