Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-04Merge branch 'jk/commit-graph-verify-fix'Junio C Hamano
Various fixes to "git commit-graph verify". * jk/commit-graph-verify-fix: commit-graph: report incomplete chains during verification commit-graph: tighten chain size check commit-graph: detect read errors when verifying graph chain t5324: harmonize sha1/sha256 graph chain corruption commit-graph: check mixed generation validation when loading chain file commit-graph: factor out chain opening function
2023-10-02Merge branch 'jc/unresolve-removal'Junio C Hamano
"checkout --merge -- path" and "update-index --unresolve path" did not resurrect conflicted state that was resolved to remove path, but now they do. * jc/unresolve-removal: checkout: allow "checkout -m path" to unmerge removed paths checkout/restore: add basic tests for --merge checkout/restore: refuse unmerging paths unless checking out of the index update-index: remove stale fallback code for "--unresolve" update-index: use unmerge_index_entry() to support removal resolve-undo: allow resurrecting conflicted state that resolved to deletion update-index: do not read HEAD and MERGE_HEAD unconditionally
2023-09-29Merge branch 'ob/am-msgfix'Junio C Hamano
The parameters to generate an error message have been corrected. * ob/am-msgfix: am: fix error message in parse_opt_show_current_patch()
2023-09-29Merge branch 'ds/stat-name-width-configuration'Junio C Hamano
"git diff" learned diff.statNameWidth configuration variable, to give the default width for the name part in the "--stat" output. * ds/stat-name-width-configuration: diff --stat: add config option to limit filename width
2023-09-29Merge branch 'jk/fsmonitor-unused-parameter'Junio C Hamano
Unused parameters in fsmonitor related code paths have been marked as such. * jk/fsmonitor-unused-parameter: run-command: mark unused parameters in start_bg_wait callbacks fsmonitor: mark unused hashmap callback parameters fsmonitor/darwin: mark unused parameters in system callback fsmonitor: mark unused parameters in stub functions fsmonitor/win32: mark unused parameter in fsm_os__incompatible() fsmonitor: mark some maybe-unused parameters fsmonitor/win32: drop unused parameters fsmonitor: prefer repo_git_path() to git_pathdup()
2023-09-28commit-graph: report incomplete chains during verificationJeff King
The load_commit_graph_chain_fd_st() function will stop loading chains when it sees an error. But if it has loaded any graph slice at all, it will return it. This is a good thing for normal use (we use what data we can, and this is just an optimization). But it's a bad thing for "commit-graph verify", which should be careful about finding any irregularities. We do complain to stderr with a warning(), but the verify command still exits with a successful return code. The new tests here cover corruption of both the base and tip slices of the chain. The corruption of the base file already works (it is the first file we look at, so when we see the error we return NULL). The "tip" case is what is fixed by this patch (it complains to stderr but still returns the base slice). Likewise the existing tests for corruption of the commit-graph-chain file itself need to be updated. We already exited non-zero correctly for the "base" case, but the "tip" case can now do so, too. Note that this also causes us to adjust a test later in the file that similarly corrupts a tip (though confusingly the test script calls this "base"). It checks stderr but erroneously expects the whole "verify" command to exit with a successful code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: detect read errors when verifying graph chainJeff King
Because it's OK to not have a graph file at all, the graph_verify() function needs to tell the difference between a missing file and a real error. So when loading a traditional graph file, we call open_commit_graph() separately from load_commit_graph_chain_fd_st(), and don't complain if the first one fails with ENOENT. When the function learned about chain files in 3da4b609bb (commit-graph: verify chains with --shallow mode, 2019-06-18), we couldn't be as careful, since the only way to load a chain was with read_commit_graph_one(), which did both the open/load as a single unit. So we'll miss errors in chain files we load, thinking instead that there was just no chain file at all. Note that we do still report some of these problems to stderr, as the loading function calls error() and warning(). But we'd exit with a successful exit code, which is wrong. We can fix that by using the recently split open/load functions for chains. That lets us treat the chain file just like a single file with respect to error handling here. An existing test (from 3da4b609bb) shows off the problem; we were expecting "commit-graph verify" to report success, but that makes no sense. We did not even verify the contents of the graph data, because we couldn't load it! I don't think this was an intentional exception, but rather just the test covering what happened to occur. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-23Merge branch 'tb/repack-existing-packs-cleanup'Junio C Hamano
The code to keep track of existing packs in the repository while repacking has been refactored. * tb/repack-existing-packs-cleanup: builtin/repack.c: extract common cruft pack loop builtin/repack.c: avoid directly inspecting "util" builtin/repack.c: store existing cruft packs separately builtin/repack.c: extract `has_existing_non_kept_packs()` builtin/repack.c: extract redundant pack cleanup for existing packs builtin/repack.c: extract redundant pack cleanup for --geometric builtin/repack.c: extract marking packs for deletion builtin/repack.c: extract structure to store existing packs
2023-09-21am: fix error message in parse_opt_show_current_patch()Oswald Buddenhagen
The argument order was incorrect. This was introduced by 246cac8505 (i18n: turn even more messages into "cannot be used together" ones, 2022-01-05). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-20Merge branch 'jc/update-index-show-index-version'Junio C Hamano
"git update-index" learns "--show-index-version" to inspect the index format version used by the on-disk index file. * jc/update-index-show-index-version: test-tool: retire "index-version" update-index: add --show-index-version update-index doc: v4 is OK with JGit and libgit2
2023-09-20Merge branch 'js/systemd-timers-wsl-fix'Junio C Hamano
Update "git maintainance" timers' implementation based on systemd timers to work with WSL. * js/systemd-timers-wsl-fix: maintenance(systemd): support the Windows Subsystem for Linux
2023-09-19run-command: mark unused parameters in start_bg_wait callbacksJeff King
The start_bg_command() function takes a callback to tell when the background-ed process is "ready". The callback receives the child_process struct as well as an extra void pointer. But curiously, neither of the two users of this interface look at either parameter! This makes some sense. The only non-test user of the API is fsmonitor, which uses fsmonitor_ipc__get_state() to connect to a single global fsmonitor daemon (i.e., the one we just started!). So we could just drop these parameters entirely. But it seems like a pretty reasonable interface for the "wait" callback to have access to the details of the spawned process, and to have room for passing extra data through a void pointer. So let's leave these in place but mark the unused ones so that -Wunused-parameter does not complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: mark unused hashmap callback parametersJeff King
Like many hashmap comparison functions, our cookies_cmp() does not look at its extra void data parameter. This should have been annotated in 02c3c59e62 (hashmap: mark unused callback parameters, 2022-08-19), but this new case was added around the same time (plus fsmonitor is not built at all on Linux, so it is easy to miss there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: mark some maybe-unused parametersJeff King
There's a bit of conditionally-compiled code in fsmonitor, so some function parameters may be unused depending on the build options: - in fsmonitor--daemon.c's try_to_run_foreground_daemon(), we take a detach_console argument, but it's only used on Windows. This seems intentional (and not mistakenly missing other platforms) based on the discussion in c284e27ba7 (fsmonitor--daemon: implement 'start' command, 2022-03-25), which introduced it. - in fsmonitor-setting.c's check_for_incompatible(), we pass the "ipc" flag down to the system-specific fsm_os__incompatible() helper. But we can only do so if our platform has such a helper. In both cases we can mark the argument as MAYBE_UNUSED. That annotates it enough to suppress the compiler's -Wunused-parameter warning, but without making it impossible to use the variable, as a regular UNUSED annotation would. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-18Merge branch 'rs/grep-no-no-or'Junio C Hamano
"git grep -e A --no-or -e B" is accepted, even though the negation of "or" did not mean anything, which has been tightened. * rs/grep-no-no-or: grep: reject --no-or
2023-09-18diff --stat: add config option to limit filename widthDragan Simic
Add new configuration option diff.statNameWidth=<width> that is equivalent to the command-line option --stat-name-width=<width>, but it is ignored by format-patch. This follows the logic established by the already existing configuration option diff.statGraphWidth=<width>. Limiting the widths of names and graphs in the --stat output makes sense for interactive work on wide terminals with many columns, hence the support for these configuration options. They don't affect format-patch because it already adheres to the traditional 80-column standard. Update the documentation and add more tests to cover new configuration option diff.statNameWidth=<width>. While there, perform a few minor code and whitespace cleanups here and there, as spotted. Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-14Merge branch 'rs/name-rev-use-opt-hidden-bool'Junio C Hamano
Simplify use of parse-options API a bit. * rs/name-rev-use-opt-hidden-bool: name-rev: use OPT_HIDDEN_BOOL for --peel-tag
2023-09-14Merge branch 'rs/grep-parseopt-simplify'Junio C Hamano
Simplify use of parse-options API a bit. * rs/grep-parseopt-simplify: grep: use OPT_INTEGER_F for --max-depth
2023-09-13builtin/repack.c: extract common cruft pack loopTaylor Blau
When generating the list of packs to store in a MIDX (when given the `--write-midx` option), we include any cruft packs both during --geometric and non-geometric repacks. But the rules for when we do and don't have to check whether any of those cruft packs were queued for deletion differ slightly between the two cases. But the two can be unified, provided there is a little bit of extra detail added in the comment to clarify when it is safe to avoid checking for any pending deletions (and why it is OK to do so even when not required). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: avoid directly inspecting "util"Taylor Blau
The `->util` field corresponding to each string_list_item is used to track the existence of some pack at the beginning of a repack operation was originally intended to be used as a bitfield. This bitfield tracked: - (1 << 0): whether or not the pack should be deleted - (1 << 1): whether or not the pack is cruft The previous commit removed the use of the second bit, but a future patch (from a different series than this one) will introduce a new use of it. So we could stop treating the util pointer as a bitfield and instead start treating it as if it were a boolean. But this would require some backtracking when that later patch is applied. Instead, let's avoid touching the ->util field directly, and instead introduce convenience functions like: - pack_mark_for_deletion() - pack_is_marked_for_deletion() Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: store existing cruft packs separatelyTaylor Blau
When repacking with the `--write-midx` option, we invoke the function `midx_included_packs()` in order to produce the list of packs we want to include in the resulting MIDX. This list is comprised of: - existing .keep packs - any pack(s) which were written earlier in the same process - any unchanged packs when doing a `--geometric` repack - any cruft packs Prior to this patch, we stored pre-existing cruft and non-cruft packs together (provided those packs are non-kept). This meant we needed an additional bit to indicate which non-kept pack(s) were cruft versus those that aren't. But alternatively we can store cruft packs in a separate list, avoiding the need for this extra bit, and simplifying the code below. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: extract `has_existing_non_kept_packs()`Taylor Blau
When there is: - at least one pre-existing packfile (which is not marked as kept), - repacking with the `-d` flag, and - not doing a cruft repack , then we pass a handful of additional options to the inner `pack-objects` process, like `--unpack-unreachable`, `--keep-unreachable`, and `--pack-loose-unreachable`, in addition to marking any packs we just wrote for promisor remotes as kept in-core (with `--keep-pack`, as opposed to the presence of a ".keep" file on disk). Because we store both cruft and non-cruft packs together in the same `existing.non_kept_packs` list, it suffices to check its `nr` member to see if it is zero or not. But a following change will store cruft- and non-cruft packs separately, meaning this check would break as a result. Prepare for this by extracting this part of the check into a new helper function called `has_existing_non_kept_packs()`. This patch does not introduce any functional changes, but prepares us to make a more isolated change in a subsequent patch. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: extract redundant pack cleanup for existing packsTaylor Blau
To remove redundant packs at the end of a repacking operation, Git uses its `remove_redundant_pack()` function in a loop over the set of pre-existing, non-kept packs. In a later commit, we will split this list into two, one for pre-existing cruft pack(s), and another for non-cruft pack(s). Prepare for this by factoring out the routine to loop over and delete redundant packs into its own function. Instead of calling `remove_redundant_pack()` directly, we now will call `remove_redundant_existing_packs()`, which itself dispatches a call to `remove_redundant_packs_1()`. Note that the geometric repacking code will still call `remove_redundant_pack()` directly, but see the previous commit for more details. Having `remove_redundant_packs_1()` exist as a separate function may seem like overkill in this patch. However, a later patch will call `remove_redundant_packs_1()` once over two separate lists, so this refactoring sets us up for that. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: extract redundant pack cleanup for --geometricTaylor Blau
To reduce the complexity of the already quite-long `cmd_repack()` implementation, extract out the parts responsible for deleting redundant packs from a geometric repack out into its own sub-routine. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: extract marking packs for deletionTaylor Blau
At the end of a repack (when given `-d`), Git attempts to remove any packs which have been made "redundant" as a result of the repacking operation. For example, an all-into-one (`-A` or `-a`) repack makes every pre-existing pack which is not marked as kept redundant. Geometric repacks (with `--geometric=<n>`) make any packs which were rolled up redundant, and so on. But before deleting the set of packs we think are redundant, we first check to see whether or not we just wrote a pack which is identical to any one of the packs we were going to delete. When this is the case, Git must avoid deleting that pack, since it matches a pack we just wrote (so deleting it may cause the repository to become corrupt). Right now we only process the list of non-kept packs in a single pass. But a future change will split the existing non-kept packs further into two lists: one for cruft packs, and another for non-cruft packs. Factor out this routine to prepare for calling it twice on two separate lists in a future patch. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13builtin/repack.c: extract structure to store existing packsTaylor Blau
The repack machinery needs to keep track of which packfiles were present in the repository at the beginning of a repack, segmented by whether or not each pack is marked as kept. The names of these packs are stored in two `string_list`s, corresponding to kept- and non-kept packs, respectively. As a consequence, many functions within the repack code need to take both `string_list`s as arguments, leading to code like this: ret = write_cruft_pack(&cruft_po_args, packtmp, pack_prefix, cruft_expiration, &names, &existing_nonkept_packs, /* <- */ &existing_kept_packs); /* <- */ Wrap up this pair of `string_list`s into a single structure that stores both. This saves us from having to pass both string lists separately, and prepares for adding additional fields to this structure. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-13Merge branch 'bc/more-git-var'Junio C Hamano
Fix-up for a topic that already has graduated. * bc/more-git-var: var: avoid a segmentation fault when `HOME` is unset
2023-09-13Merge branch 'ew/hash-with-openssl-evp'Junio C Hamano
Fix-up new-ish code to support OpenSSL EVP API. * ew/hash-with-openssl-evp: treewide: fix various bugs w/ OpenSSL 3+ EVP API
2023-09-13Merge branch 'jk/unused-post-2.42-part2'Junio C Hamano
Unused parameters to functions are marked as such, and/or removed, in order to bring us closer to -Wunused-parameter clean. * jk/unused-post-2.42-part2: parse-options: mark unused parameters in noop callback interpret-trailers: mark unused "unset" parameters in option callbacks parse-options: add more BUG_ON() annotations merge: do not pass unused opt->value parameter parse-options: mark unused "opt" parameter in callbacks parse-options: prefer opt->value to globals in callbacks checkout-index: delay automatic setting of to_tempfile format-patch: use OPT_STRING_LIST for to/cc options merge: simplify parsing of "-n" option merge: make xopts a strvec
2023-09-13update-index: add --show-index-versionJunio C Hamano
"git update-index --index-version N" is used to set the index format version to a specific version, but there was no way to query the current version used in the on-disk index file. Teach the command a new "--show-index-version" option, and also teach the "--index-version N" option to report what the version was when run with the "--verbose" option. Helped-by: Linus Arver <linusa@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-11maintenance(systemd): support the Windows Subsystem for LinuxJohannes Schindelin
When running in the Windows Subsystem for Linux (WSL), it is usually necessary to use the Git Credential Manager for authentication when performing the background fetches. This requires interoperability between the Windows Subsystem for Linux and the Windows host to work, which uses so-called vsocks, i.e. sockets intended for communcations between virtual machines and the host they are running on. However, when Git is configured to run background maintenance via `systemd`, the address families available to those maintenance processes are restricted, and did not include `AF_VSOCK`. This leads to problems e.g. when a background fetch tries to access github.com: systemd[437]: Starting Optimize Git repositories data... git[747387]: WSL (747387) ERROR: UtilBindVsockAnyPort:285: socket failed 97 git[747381]: fatal: could not read Username for 'https://github.com': No such device or address git[747381]: error: failed to prefetch remotes git[747381]: error: task 'prefetch' failed systemd[437]: git-maintenance@hourly.service: Main process exited, code=exited, status=1/FAILURE systemd[437]: git-maintenance@hourly.service: Failed with result 'exit-code'. systemd[437]: Failed to start Optimize Git repositories data. Address this (pun intended) by adding the `AF_VSOCK` address family to the allow list. This fixes https://github.com/microsoft/git/issues/604. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-08Merge branch 'dd/format-patch-rfc-updates'Junio C Hamano
"git format-patch --rfc --subject-prefix=<foo>" used to ignore the "--subject-prefix" option and used "[RFC PATCH]"; now we will add "RFC" prefix to whatever subject prefix is specified. This is a backward compatible change that may deserve a note. * dd/format-patch-rfc-updates: format-patch: --rfc honors what --subject-prefix sets
2023-09-08Merge branch 'jk/unused-post-2.42'Junio C Hamano
Unused parameters to functions are marked as such, and/or removed, in order to bring us closer to -Wunused-parameter clean. * jk/unused-post-2.42: (22 commits) update-ref: mark unused parameter in parser callbacks gc: mark unused descriptors in scheduler callbacks bundle-uri: mark unused parameters in callbacks fetch: mark unused parameter in ref_transaction callback credential: mark unused parameter in urlmatch callback grep: mark unused parmaeters in pcre fallbacks imap-send: mark unused parameters with NO_OPENSSL worktree: mark unused parameters in noop repair callback negotiator/noop: mark unused callback parameters add-interactive: mark unused callback parameters grep: mark unused parameter in output function test-trace2: mark unused argv/argc parameters trace2: mark unused config callback parameter trace2: mark unused us_elapsed_absolute parameters stash: mark unused parameter in diff callback ls-tree: mark unused parameter in callback commit-graph: mark unused data parameters in generation callbacks worktree: mark unused parameters in each_ref_fn callback pack-bitmap: mark unused parameters in show_object callback ref-filter: mark unused parameters in parser callbacks ...
2023-09-08Merge branch 'tb/multi-cruft-pack'Junio C Hamano
Use of --max-pack-size to allow multiple packfiles to be created is now supported even when we are sending unreachable objects to cruft packs. * tb/multi-cruft-pack: Documentation/gitformat-pack.txt: drop mixed version section Documentation/gitformat-pack.txt: remove multi-cruft packs alternative builtin/pack-objects.c: support `--max-pack-size` with `--cruft` builtin/pack-objects.c: remove unnecessary strbuf_reset()
2023-09-07grep: reject --no-orRené Scharfe
Since 3e230fa1b2 (grep: use parseopt, 2009-05-07) git grep has been accepting the option --no-or. It does the same as --or: nothing. That's confusing and unintended. Forbid negating --or. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06var: avoid a segmentation fault when `HOME` is unsetJohannes Schindelin
The code introduced in 576a37fccbf (var: add attributes files locations, 2023-06-27) paid careful attention to use `xstrdup()` for pointers known never to be `NULL`, and `xstrdup_or_null()` otherwise. One spot was missed, though: `git_attr_global_file()` can return `NULL`, when the `HOME` variable is not set (and neither `XDG_CONFIG_HOME`), a scenario not too uncommon in certain server scenarios. Fix this, and add a test case to avoid future regressions. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: brian m. carlson <bk2204@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06grep: use OPT_INTEGER_F for --max-depthRené Scharfe
a91f453f64 (grep: Add --max-depth option., 2009-07-22) added the option --max-depth, defining it using a positional struct option initializer of type OPTION_INTEGER. It also sets defval to 1 for some reason, but that value would only be used if the flag PARSE_OPT_OPTARG was given. Use the macro OPT_INTEGER_F instead to standardize the definition and specify only the necessary values. This also normalizes argh to N_("n") as a side-effect, which is OK. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06name-rev: use OPT_HIDDEN_BOOL for --peel-tagRené Scharfe
adfc1857bd (describe: fix --contains when a tag is given as input, 2013-07-18) added the option --peel-tag, defining it using a positional struct option initializer and a comment indicating that it's intended to be a hidden OPT_BOOL. 4741edd549 (Remove deprecated OPTION_BOOLEAN for parsing arguments, 2013-08-03) added the macro OPT_HIDDEN_BOOL, which allows to express this more succinctly. Use it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06interpret-trailers: mark unused "unset" parameters in option callbacksJeff King
There are a few parse-option callbacks that do not look at their "unset" parameters, but also do not set PARSE_OPT_NONEG. At first glance this seems like a bug, as we'd ignore "--no-if-exists", etc. But they do work fine, because when "unset" is true, then "arg" is NULL. And all three functions pass "arg" on to helper functions which do the right thing with the NULL. Note that this shortcut would not be correct if any callback used PARSE_OPT_NOARG (in which case "arg" would be NULL but "unset" would be false). But none of these do. So the code is fine as-is. But we'll want to mark the unused "unset" parameters to quiet -Wunused-parameter. I've also added a comment to make this rather subtle situation more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06parse-options: add more BUG_ON() annotationsJeff King
These callbacks are similar to the ones touched by 517fe807d6 (assert NOARG/NONEG behavior of parse-options callbacks, 2018-11-05), but were either missed in that commit (the one in add.c) or were added later (the one in log.c). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06merge: do not pass unused opt->value parameterJeff King
The option_parse_strategy() callback does not look at opt->value; instead it calls append_strategy(), which manipulates the global use_strategies array directly. But the OPT_CALLBACK declaration assigns "&use_strategies" to opt->value. One could argue this is good, as it tells the reader what we generally expect the callback to do. But it is also bad, because it can mislead you into thinking that swapping out "&use_strategies" there might have any effect. Let's switch it to pass NULL (which is what every other "does not bother to look at opt->value" callback does). If you want to know what the callback does, it's easy to read the function itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06parse-options: mark unused "opt" parameter in callbacksJeff King
The previous commit argued that parse-options callbacks should try to use opt->value rather than touching globals directly. In some cases, however, that's awkward to do. Some callbacks touch multiple variables, or may even just call into an abstracted function that does so. In some of these cases we _could_ convert them by stuffing the multiple variables into a single struct and passing the struct pointer through opt->value. But that may make other parts of the code less readable, as the struct relationship has to be mentioned everywhere. Let's just accept that these cases are special and leave them as-is. But we do need to mark their "opt" parameters to satisfy -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06parse-options: prefer opt->value to globals in callbacksJeff King
We have several parse-options callbacks that ignore their "opt" parameters entirely. This is a little unusual, as we'd normally put the result of the parsing into opt->value. In the case of these callbacks, though, they directly manipulate global variables instead (and in most cases the caller sets opt->value to NULL in the OPT_CALLBACK declaration). The immediate symptom we'd like to deal with is that the unused "opt" variables trigger -Wunused-parameter. But how to fix that is debatable. One option is to annotate them with UNUSED. But another is to have the caller pass in the appropriate variable via opt->value, and use it. That has the benefit of making the callbacks reusable (in theory at least), and makes it clear from the OPT_CALLBACK declaration which variables will be affected (doubly so for the cases in builtin/fast-export.c, where we do set opt->value, but it is completely ignored!). The slight downside is that we lose type safety, since they're now passing through void pointers. I went with the "just use them" approach here. The loss of type safety is unfortunate, but that is already an issue with most of the other callbacks. If we want to try to address that, we should do so more consistently (and this patch would prepare these callbacks for whatever we choose to do there). Note that in the cases in builtin/fast-export.c, we are passing anonymous enums. We'll have to give them names so that we can declare the appropriate pointer type within the callbacks. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-06checkout-index: delay automatic setting of to_tempfileJeff King
Using --stage=all requires writing to tempfiles, since we cannot put multiple stages into a single file. So --stage=all implies --temp. But we do so by setting to_tempfile in the options callback for --stage, rather than after all options have been parsed. This leads to two bugs: 1. If you run "checkout-index --stage=all --stage=2", this should not imply --temp, but it currently does. The callback cannot just unset to_tempfile when it sees the "2" value, because it no longer knows if its value was from the earlier --stage call, or if the user specified --temp explicitly. 2. If you run "checkout-index --stage=all --no-temp", the --no-temp will overwrite the earlier implied --temp. But this mode of operation cannot work, and the command will fail with "<path> already exists" when trying to write the higher stages. We can fix both by lazily setting to_tempfile. We'll make it a tristate, with -1 as "not yet given", and have --stage=all enable it only after all options are parsed. Likewise, after all options are parsed we can detect and reject the bogus "--no-temp" case. Note that this does technically change the behavior for "--stage=all --no-temp" for paths which have only one stage present (which accidentally worked before, but is now forbidden). But this behavior was never intended, and you'd have to go out of your way to try to trigger it. The new tests cover both cases, as well the general "--stage=all implies --temp", as most of the other tests explicitly say "--temp". Ironically, the test "checkout --temp within subdir" is the only one that _doesn't_ use "--temp", and so was implicitly covering this case. But it seems reasonable to have a more explicit test alongside the other related ones. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01Merge branch 'ob/format-patch-description-file'Junio C Hamano
"git format-patch" learns a way to feed cover letter description, that (1) can be used on detached HEAD where there is no branch description available, and (2) also can override the branch description if there is one. * ob/format-patch-description-file: format-patch: add --description-file option
2023-09-01Merge branch 'jk/diff-result-code-cleanup'Junio C Hamano
"git diff --no-such-option" and other corner cases around the exit status of the "diff" command has been corrected. * jk/diff-result-code-cleanup: diff: drop useless "status" parameter from diff_result_code() diff: drop useless return values in git-diff helpers diff: drop useless return from run_diff_{files,index} functions diff: die when failing to read index in git-diff builtin diff: show usage for unknown builtin_diff_files() options diff-files: avoid negative exit value diff: spell DIFF_INDEX_CACHED out when calling run_diff_index()
2023-09-01treewide: fix various bugs w/ OpenSSL 3+ EVP APIEric Wong
The OpenSSL 3+ EVP API for SHA-* cannot support our prior use cases supported by other SHA-* implementations. It has the following differences: 1. ->init_fn is required before all use 2. struct assignments don't work and requires ->clone_fn 3. can't support ->update_fn after ->final_*fn While fixing cases 1 and 2 is merely the matter of calling ->init_fn and ->clone_fn as appropriate, fixing case 3 requires calling ->final_*fn on a temporary context that's cloned from the primary context. Reported-by: Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/ZPCL11k38PXTkFga@debian.me/ Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Fixes: 3e440ea0aba0 ("sha256: avoid functions deprecated in OpenSSL 3+") Fixes: bda9c12073e7 ("avoid SHA-1 functions deprecated in OpenSSL 3+") Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01format-patch: use OPT_STRING_LIST for to/cc optionsJeff King
The to_callback() and cc_callback() functions are identical to the generic parse_opt_string_list() function (except that they don't handle optional arguments, but that's OK because their callers do not use the OPTARG flag). Let's simplify the code by using OPT_STRING_LIST. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01merge: simplify parsing of "-n" optionJeff King
The "-n" option is implemented by an option callback, as it is really a "reverse bool". If given, it sets show_diffstat to 0. In theory, when negated, it would set the same flag to 1. But it's not possible to trigger that, since short options cannot be negated. So in practice this is really just a SET_INT to 0. Let's use that instead, which shortens the code. Note that negation here would do the wrong thing (as with any SET_INT with a value of "0"). We could specify PARSE_OPT_NONEG to future-proof ourselves against somebody adding a long option name (which would make it possible to negate). But there's not much point: 1. Nobody is going to do that, because the negated form already exists, and is called "--stat" (which is defined separately so that "--no-stat" works). 2. If they did, the BUG() check added by 3284b93862 (parse-options: disallow negating OPTION_SET_INT 0, 2023-08-08) will catch it (and that check is smart enough to realize that our short-only option is OK). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-01merge: make xopts a strvecJeff King
The "xopts" variable uses a custom array with ALLOC_GROW(). Using a strvec simplifies things a bit. We need fewer variables, and we can also ditch our custom parseopt callback in favor of OPT_STRVEC(). As a bonus, this means that "--no-strategy-option", which was previously a silent noop, now does something useful: like other list-like options, it will clear the list of -X options seen so far. This matches the behavior of revert/cherry-pick, which made the same change in fb60b9f37f (sequencer: use struct strvec to store merge strategy options, 2023-04-10). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>