summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorLines
2025-05-15sequencer: stop pretending that an assignment is a conditionJohannes Schindelin-3/+6
In 3e81bccdf3 (sequencer: factor out todo command name parsing, 2019-06-27), a `return` statement was introduced that basically was a long sequence of conditions, combined with `&&`, except for the last condition which is not really a condition but an assignment. The point of this construct was to return 1 (i.e. `true`) from the function if all of those conditions held true, and also assign the `bol` pointer to the end of the parsed command. Some static analyzers are really unhappy about such constructs. And human readers are at least puzzled, if not confused, by seeing a single `=` inside a chain of conditions where they would have expected to see `==` instead and, based on experience, immediately suspect a typo. Let's help all of this by turning this into the more verbose, more readable form of an `if` construct that both assigns the pointer as well as returns 1 if all of the conditions hold true. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15bundle-uri: avoid using undefined output of `sscanf()`Johannes Schindelin-5/+7
In c429bed102 (bundle-uri: store fetch.bundleCreationToken, 2023-01-31) code was introduced that assumes that an `sscanf()` call leaves its output variables unchanged unless the return value indicates success. However, the POSIX documentation makes no such guarantee: https://pubs.opengroup.org/onlinepubs/9699919799/functions/sscanf.html So let's make sure that the output variable `maxCreationToken` is always well-defined. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15commit-graph: avoid using stale stack addressesJohannes Schindelin-0/+9
The code is a bit too hard to reason about to fully assess whether the `fill_commit_graph_info()` function is called at all after `write_commit_graph()` returns (and hence the stack variable `topo_levels` goes out of context). Let's simply make sure that the stack address is no longer used at that stage, thereby making the code quite a bit easier to reason about. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15trace2: avoid "futile conditional"Johannes Schindelin-19/+5
CodeQL reports empty `if` blocks that only contain a comment as "futile conditional". The comment talks about potential plans to turn this into a warning, but that seems not to have been necessary. Replace the entire construct with a concise comment. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15Avoid redundant conditionsJohannes Schindelin-2/+2
While `if (i <= 0) ... else if (i > 0) ...` is technically equivalent to `if (i <= 0) ... else ...`, the latter is vastly easier to read because it avoids writing out a condition that is unnecessary. Let's drop such unnecessary conditions. Pointed out by CodeQL. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15fetch: avoid unnecessary work when there is no current branchJohannes Schindelin-1/+1
As pointed out by CodeQL, `branch_get()` may return `NULL`, in which case `branch_has_merge_config()` would return early, but we can even avoid enumerating the refs prefixes in that case, saving even more CPU cycles. Technically, we should enclose these two statements in an `if (branch) {...}` block, but the indentation is already quite deep, therefore I refrained from doing that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15has_dir_name(): make code more obviousJohannes Schindelin-42/+13
One thing that might be non-obvious to readers (or to analyzers like CodeQL) is that the function essentially does nothing when the Git index is empty, and in particular that it does not look at the value of `len_eq_last` (which would be uninitialized at that point). Let's make this much easier to understand, by returning early if the Git index is empty, and by avoiding empty `else` blocks. This commit changes indentation and is hence best viewed using `--ignore-space-change`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15upload-pack: rename `enum` to reflect the operationJohannes Schindelin-17/+17
While 3145ea957d (upload-pack: introduce fetch server command, 2018-03-15) added support for the `fetch` command, from the server's point of view it is an upload, and hence the `enum` should really be called `upload_state` instead of `fetch_state`. Likewise, rename its values. This also helps unconfuse CodeQL which would otherwise be at sixes or sevens about having _two_ non-local definitions of the same `enum` with the same values. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15commit-graph: avoid malloc'ing a local variableJohannes Schindelin-72/+69
We do need a context to write the commit graph, but that context is only needed during the life time of `commit_graph_write()`, therefore it can easily be a stack variable. This also helps CodeQL recognize that it is safe to assign the address of other local variables to the context's fields. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15fetch: carefully clear local variable's address after useJohannes Schindelin-0/+1
As pointed out by CodeQL, it is a potentially dangerous practice to store local variables' addresses in non-local structs. Yet this is exactly what happens with the `acked_commits` attribute that is used in `cmd_fetch()`: The pointer to a local variable is assigned to it. Now, it is Git's convention that `cmd_*()` functions are essentially only returning just before exiting the process, therefore there is little danger that this attribute is used after the code flow returns from that function. However, code in `cmd_*()` function is often so useful that it gets lifted into a library function, at which point this issue could become a real problem. Let's make sure to clear the `acked_commits` attribute out after it was used, and before the function returns (at which point the address would go stale). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15commit: simplify codeJohannes Schindelin-1/+1
The difference of two unsigned integers is defined to be unsigned, and therefore it is misleading to check whether it is greater than zero (instead, the more natural way would be to check whether the difference is zero or not). Let's instead avoid the subtraction altogether, and compare the two operands directly, which makes the code more obvious as a side effect. Pointed out by CodeQL's rule with the ID `cpp/unsigned-difference-expression-compared-zero`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-15git-gui: do not end the commit message with an empty lineJohannes Sixt-4/+2
The commit message is processed to remove unnecessary empty lines. In particular, it is ensured that the text ends with at most one LF character. This one is always present, because the Tk text widget ensures that is present. However, did not consider that the processed text is written to the commit message file using `puts`, which also appends a LF character, so that the final commit message ends with two LF. Trim all trailing LF characters, and while we are here, use `string trim`, which lets us remove the leading LF in the same command. Reported-by: Gareth Fenn <garethfenn@gmail.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2025-05-15gitk: do not hard-code color of search results in commit listAlexander Ogorodov-2/+2
A global variable exists that holds the color name used to highlight search results everywhere, except that in the commit list the color is still hard-coded to "yellow". Use the global variable there as well. Signed-off-by: Alexander Ogorodov <bnfour@bnfour.net>
2025-05-14replay: replace the_repository with repo parameter passed to cmd_replay ()Elijah Newren-30/+35
Replace the_repository everywhere with repo, feed repo from cmd_replay() to all the other functions in the file that need it, and remove the UNUSED annotation on repo. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-14packed-backend: mmap large "packed-refs" file during fsckshejialuo-12/+7
During fsck, we use "strbuf_read" to read the content of "packed-refs" without using mmap mechanism. This is a bad practice which would consume more memory than using mmap mechanism. Besides, as all code paths in "packed-backend.c" use this way, we should make "fsck" align with the current codebase. As we have introduced the helper function "allocate_snapshot_buffer", we can simply use this function to use mmap mechanism. Suggested-by: Jeff King <peff@peff.net> Suggested-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: shejialuo <shejialuo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-14packed-backend: extract snapshot allocation in `load_contents`shejialuo-22/+31
"load_contents" would choose which way to load the content of the "packed-refs". However, we cannot directly use this function when checking the consistency due to we don't want to open the file. And we also need to reuse the logic to avoid causing repetition. Let's create a new helper function "allocate_snapshot_buffer" to extract the snapshot allocation logic in "load_contents" and update the "load_contents" to align with the behavior. Suggested-by: Jeff King <peff@peff.net> Suggested-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: shejialuo <shejialuo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-14packed-backend: fsck should warn when "packed-refs" file is emptyshejialuo-0/+33
We assume the "packed-refs" won't be empty and instead has at least one line in it (even when there are no refs packed, there is the file header line). Because there is no terminating LF in the empty file, we will report "packedRefEntryNotTerminated(ERROR)" to the user. However, the runtime code paths would accept an empty "packed-refs" file, for example, "create_snapshot" would simply return the "snapshot" without checking the content of "packed-refs". So, we should skip checking the content of "packed-refs" when it is empty during fsck. After 694b7a1999 (repack_without_ref(): write peeled refs in the rewritten file, 2013-04-22), we would always write a header into the "packed-refs" file. So, versions of Git that are not too ancient never write such an empty "packed-refs" file. As an empty file often indicates a sign of a filesystem-level issue, the way we want to resolve this inconsistency is not make everybody totally silent but notice and report the anomaly. Let's create a "FSCK_INFO" message id "EMPTY_PACKED_REFS_FILE" to report to the users that "packed-refs" is empty. Signed-off-by: shejialuo <shejialuo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-14scalar reconfigure: improve --maintenance docsDerrick Stolee-9/+8
The --maintenance option for 'scalar reconfigure' has three possible values. Improve the documentation by specifying the option in the -h help menu and usage information. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-14gitk: place file name arguments after options in msgfmt callJohannes Sixt-1/+1
The build process fails in POSIXLY_CORRECT mode: $ gitk@master:1005> POSIXLY_CORRECT=1 make * new Tcl/Tk interpreter location GEN gitk-wish Generating catalog po/zh_cn.msg msgfmt --statistics --tcl po/zh_cn.po -l zh_cn -d po/ msgfmt: --tcl requires a "-l locale" specification Try 'msgfmt --help' for more information. make: *** [Makefile:76: po/zh_cn.msg] Error 1 The reason is that option arguments cannot occur after the first non-option argument. Move the file name last. Reported-by: Nathan Royce <nroycea+kernel@gmail.com> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2025-05-13send-email: try to get fqdn by running hostname -f on Linux and macOSAditya Garg-1/+15
`hostname` is a popular command available on both Linux and macOS. As per the man-page[1], `hostname -f` command returns the fully qualified domain name (FQDN) of the system. The current Net::Domain perl module being used in the script for the same has been quite unrealiable in many cases. Thankfully, we now have a better check for valid_fqdn, which does reject the invalid FQDNs given by this module properly, but at the same time, it will result in a fallback to 'localhost.localdomain' being used. `hostname -f` has been quite reliable (probably even more reliable than the Net::Domain module) and before falling back to 'localhost.localdomain', we should try to use it. Interestingly, the `hostname` command is actually used by perl modules like Net::Domain[2] and Sys::Hostname[3] to get the hostname. So, lets give `hostname -f` a chance as well! [1]: https://man7.org/linux/man-pages/man1/hostname.1.html [2]: https://github.com/Perl/perl5/blob/blead/cpan/libnet/lib/Net/Domain.pm#L88 [3]: https://github.com/Perl/perl5/blob/blead/ext/Sys-Hostname/Hostname.pm#L93 Signed-off-by: Aditya Garg <gargaditya08@live.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-13The fourteenth batchJunio C Hamano-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-13Merge branch 'kj/glob-path-with-special-char'Junio C Hamano-1/+432
"git add 'f?o'" did not add 'foo' if 'f?o', an unusual pathname, also existed on the working tree, which has been corrected. * kj/glob-path-with-special-char: dir.c: literal match with wildcard in pathspec should still glob
2025-05-13Merge branch 'kh/docfixes'Junio C Hamano-2/+2
Docfixes. * kh/docfixes: doc: branch: fix inline-verbatim doc: reflog: fix `drop` subheading
2025-05-13Merge branch 'js/ci-buildsystems-cleanup'Junio C Hamano-1950/+0
Code clean-up around stale CI elements and building with Visual Studio. * js/ci-buildsystems-cleanup: config.mak.uname: drop the `vcxproj` target contrib/buildsystems: drop support for building . vcproj/.vcxproj files ci: stop linking the `prove` cache
2025-05-13Merge branch 'ps/ci-test-aggreg-fix-for-meson'Junio C Hamano-0/+1
Test result aggregation did not work in Meson based CI jobs. * ps/ci-test-aggreg-fix-for-meson: ci: fix aggregation of test results with Meson
2025-05-13Merge branch 'en/get-tree-entry-doc'Junio C Hamano-5/+8
Doc update. * en/get-tree-entry-doc: tree-walk.h: fix incorrect API comment
2025-05-13gitlab-ci: always run MSVC-based Meson jobPatrick Steinhardt-1/+0
With 7304bd2bc39 (ci: wire up Visual Studio build with Meson, 2025-01-22) we have introduced a CI job that builds and tests Git with Microsoft Visual Studio via Meson. This job is only being executed by default on GitHub Workflows though -- on GitLab CI it is marked as a "manual" job, so the developer has to actively trigger these jobs. The consequence of this split is that any breakage specific to this job is only noticed by developers who mainly work with GitHub. Let's improve this situation by also running the job by default on GitLab CI. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-13git-gui: wire up support for the Meson build systemPatrick Steinhardt-0/+261
The Git project has started to wire up Meson as a build system in Git v2.48.0. Wire up support for Meson in "git-gui" so that we can trivially include it as a subproject in Git. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: stop including GIT-VERSION-FILE filePatrick Steinhardt-5/+2
The "GITGUI_VERSION" variable is made available by generating and including the "GIT-VERSION-FILE" file. Its value has been used in various build steps, but in the preceding commits we have refactored those to instead source the "GIT-VERSION-FILE" directly. As a result, the variable is now only used in a single recipe, and this use can be trivially replaced with sed(1). Refactor the recipe to do so and stop including "GIT-VERSION-FILE" to simplify the build process. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: extract script to generate macOS appPatrick Steinhardt-20/+34
Extract script to generate the macOS app. This change allows us to reuse the build logic with the Meson build system. Note that as part of this change we also modify the TKEXECUTABLE variable to track its full path. Like this we don't have to propagate both the TKEXECUTABLE and TKFRAMEWORK variables into the script, and the basename can be trivially computed from TKEXECUTABLE anyway. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: extract script to generate macOS wrapperPatrick Steinhardt-14/+40
Extract script to generate the macOS wrapper for git-gui. This change allows us to reuse the build logic with the Meson build system. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: extract script to generate "tclIndex"Patrick Steinhardt-14/+34
Extract script to generate "tclIndex". This change allows us to reuse the build logic with the Meson build system. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: extract script to generate "git-gui"Patrick Steinhardt-11/+30
Extract script to generate "git-gui". This change allows us to reuse the build logic with the Meson build system. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: drop no-op GITGUI_SCRIPT replacementPatrick Steinhardt-2/+0
The value of the GITGUI_SCRIPT variable is only used in a single place as part of an sed(1) script that massages the "git-gui.sh" script. Interestingly, this specific replacement does seem to be a no-op: we replace "^ argv0=$$0" with " argv=$(GITGUI_SCRIPT)", which has a value of "$$0". The result would thus be completely unchanged. Drop the replacement and its variable. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: make output of GIT-VERSION-GEN source'ablePatrick Steinhardt-3/+3
The output of GIT-VERSION-GEN can be sourced by our Makefile to make the version available there. The output has a couple of spaces around the equals sign, which is perfectly valid for parsing it in our Makefile. But in subsequent steps we'll also want to source the file in a couple of newly-introduced shell scripts, but having spaces around variable assignments is invalid there. Prepare for this step by dropping the spaces surrounding the equals sign. Like this, we can easily use the same file both in our Makefile and in shell scripts. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: prepare GIT-VERSION-GEN for out-of-tree buildsPatrick Steinhardt-15/+29
The GIT-VERSION-GEN unconditionally writes version information into the source directory in the form of the "GIT-VERSION-FILE". We are about to introduce the Meson build system though, which enforces out-of-tree builds by default, and in that context we cannot continue to write version information into the source tree. Prepare the script for out-of-tree builds by treating the source directory different from the output file. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-13git-gui: replace GIT-GUI-VARS with GIT-GUI-BUILD-OPTIONSPatrick Steinhardt-21/+23
The GIT-GUI-VARS file is used to track whether any of our build options has changed. Unfortunately, the format of that file does not allow us to propagate those build options to other scripts. But as we are about to introduce support for the Meson build system, we will extract a couple of scripts to deduplicate core build logic across Makefiles and Meson. With this refactoring, it will become necessary to make build options more widely accessible. Replace GIT-GUI-VARS with a new GIT-GUI-BUILD-OPTIONS file that is being populated from a template. This file can easily be sourced from build scripts in subsequent steps. Signed-off-by: Patrick Steinhardt <ps@pks.im>
2025-05-12whatschanged: list it in BreakingChanges documentJunio C Hamano-2/+17
This can be squashed into the previous step. That is how our "git pack-redundant" conversion did. Theoretically, however, those who want to gauge the need to keep the command by exposing their users to patches before this one may want to wait until their experiment finishes before they formally say "this will go away". This change is made into a separate patch from the previous step precisely to help those folks. While at it, update the documentation page to use the new [synopsis] facility to mark-up the SYNOPSIS part. Helped-by: Elijah Newren <newren@gmail.com> [en: typofix] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12whatchanged: remove when built with WITH_BREAKING_CHANGESJunio C Hamano-15/+66
As we made "git whatchanged" require "--i-still-use-this" and asked the users to report if they still want to use it, the logical next step is to allow us build Git without "whatchanged" to prepare for its eventual removal. If we were to follow the pattern established in 8ccc75c2 (remote: announce removal of "branches/" and "remotes/", 2025-01-22), we can do this together with the documentation update to officially list that the command will be removed in the BreakingChanges document, but let's just keep the changes separate just in case we want to proceed a bit slower. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12whatchanged: require --i-still-use-thisJunio C Hamano-7/+37
The documentation of "git whatchanged" is pretty explicit that the command was retained for historical reasons to help those whose fingers cannot be retrained. Let's see if they still are finding it hard to type "git log --raw" instead of "git whatchanged" by marking the command as "nominated for removal", and require "--i-still-use-this" on the command line. Adjust the tests so that the option is passed when we invoke the command. In addition, we test that the command fails when "--i-still-use-this" is not given. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12tests: prepare for a world without whatchangedJunio C Hamano-7/+7
Some tests on fast-import run "git whatchanged" without even checking the output from the command. It is tempting to remove the calls altogether since they are not doing anything useful, but they presumably were added there while the tests were developed to manually sanity check which paths were touched. Replace these calls with "git log --raw", which is a rough equivalent in the more modern Git. This does not remove "git whatchanged", but we no longer have to worry about adjusting these places when we eventually do. Helped-by: Elijah Newren <newren@gmail.com> [en: log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12The thirteenth batchJunio C Hamano-0/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12Merge branch 'ps/meson-bin-sh'Junio C Hamano-1/+11
Meson-based build framework update. * ps/meson-bin-sh: meson: prefer shell at "/bin/sh" meson: report detected runtime executable paths
2025-05-12Merge branch 'ng/xdiff-truly-minimal'Junio C Hamano-2/+18
"git diff --minimal" used to give non-minimal output when its optimization kicked in, which has been disabled. * ng/xdiff-truly-minimal: xdiff: disable cleanup_records heuristic with --minimal
2025-05-12Merge branch 'ds/fix-thin-fix'Junio C Hamano-28/+216
"git index-pack --fix-thin" used to abort to prevent a cycle in delta chains from forming in a corner case even when there is no such cycle. * ds/fix-thin-fix: index-pack: allow revisiting REF_DELTA chains t5309: create failing test for 'git index-pack' test-tool: add pack-deltas helper
2025-05-12Merge branch 'jc/ci-skip-unavailable-external-software'Junio C Hamano-13/+8
Further refinement on CI messages when an optional external software is unavailable (e.g. due to third-party service outage). * jc/ci-skip-unavailable-external-software: ci: download JGit from maven, not eclipse.org ci: update the message for unavailble third-party software
2025-05-12Merge branch 'ps/object-store-cleanup'Junio C Hamano-289/+278
Further code clean-up in the object-store layer. * ps/object-store-cleanup: object-store: drop `repo_has_object_file()` treewide: convert users of `repo_has_object_file()` to `has_object()` object-store: allow fetching objects via `has_object()` object-store: move function declarations to their respective subsystems object-store: move and rename `odb_pack_keep()` object-store: drop `loose_object_path()` object-store: move `struct packed_git` into "packfile.h"
2025-05-12Merge branch 'ag/send-email-outlook'Junio C Hamano-1/+45
Update send-email to work better with Outlook's smtp server. * ag/send-email-outlook: send-email: add --[no-]outlook-id-fix option send-email: retrieve Message-ID from outlook SMTP server
2025-05-12doc: prepare for a world without whatchangedJunio C Hamano-3/+3
Some documentation examples reference "whatchanged", either as a placeholder command or an example of source structure. To reduce the need for future edits when `whatchanged` is removed, replace these references with alternatives: - In `MyFirstObjectWalk.adoc`, use `version` as the nearby anchor point for `walken`, instead of `whatchanged`. - In `user-manual.adoc`, cite `show` instead of `whatchanged` as a command whose source lives in the same file as `log`. Helped-by: Elijah Newren <newren@gmail.com> [en: log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-12you-still-use-that??: help deprecating commands for removalJunio C Hamano-8/+21
Commands slated for removal like "git pack-redundant" now require an explicit "--i-still-use-this" option to run. This is to discourage casual use and surface their pending deprecation to users. The warning message is long, so factor it into a helper function you_still_use_that() to simplify reuse by other commands. Also add a missing test to ensure this enforcement works for "pack-redundant". Helped-by: Elijah Newren <newren@gmail.com> [en: log message] Signed-off-by: Junio C Hamano <gitster@pobox.com>