summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2021-12-07refs: introduce REF_SKIP_OID_VERIFICATION flagLibravatar Han-Wen Nienhuys3-5/+7
This lets the ref-store test helper write non-existent or unparsable objects into the ref storage. Use this to make t1006 and t3800 independent of the files storage backend. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-07test-ref-store: plug memory leak in cmd_delete_refsLibravatar Han-Wen Nienhuys1-1/+4
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-07test-ref-store: parse symbolic flag constantsLibravatar Han-Wen Nienhuys2-9/+60
This lets tests use REF_XXXX constants instead of hardcoded integers. The flag names should be separated by a ','. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-07test-ref-store: remove force-create argument for create-reflogLibravatar Han-Wen Nienhuys3-5/+4
Nobody uses force_create=0, so this flag is unnecessary. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'mc/clean-smudge-with-llp64'Libravatar Junio C Hamano3-4/+47
The clean/smudge conversion code path has been prepared to better work on platforms where ulong is narrower than size_t. * mc/clean-smudge-with-llp64: clean/smudge: allow clean filters to process extremely large files odb: guard against data loss checking out a huge file git-compat-util: introduce more size_t helpers odb: teach read_blob_entry to use size_t t1051: introduce a smudge filter test for extremely large files test-lib: add prerequisite for 64-bit platforms test-tool genzeros: generate large amounts of data more efficiently test-genzeros: allow more than 2G zeros in Windows
2021-11-29Merge branch 'tb/plug-pack-bitmap-leaks'Libravatar Junio C Hamano1-1/+2
Leakfix. * tb/plug-pack-bitmap-leaks: pack-bitmap.c: more aggressively free in free_bitmap_index() pack-bitmap.c: don't leak type-level bitmaps midx.c: write MIDX filenames to strbuf builtin/multi-pack-index.c: don't leak concatenated options builtin/repack.c: avoid leaking child arguments builtin/pack-objects.c: don't leak memory via arguments t/helper/test-read-midx.c: free MIDX within read_midx_file() midx.c: don't leak MIDX from verify_midx_file midx.c: clean up chunkfile after reading the MIDX
2021-11-29Merge branch 'tp/send-email-completion'Libravatar Junio C Hamano1-0/+3
The command line complation for "git send-email" options have been tweaked to make it easier to keep it in sync with the command itself. * tp/send-email-completion: send-email docs: add format-patch options send-email: programmatically generate bash completions
2021-11-29Merge branch 'jc/fix-ref-sorting-parse'Libravatar Junio C Hamano2-1/+37
Things like "git -c branch.sort=bogus branch new HEAD", i.e. the operation modes of the "git branch" command that do not need the sort key information, no longer errors out by seeing a bogus sort key. * jc/fix-ref-sorting-parse: for-each-ref: delay parsing of --sort=<atom> options
2021-11-29Merge branch 'so/stash-staged'Libravatar Junio C Hamano1-0/+11
"git stash" learned the "--staged" option to stash away what has been added to the index (and nothing else). * so/stash-staged: stash: get rid of unused argument in stash_staged() stash: implement '--staged' option for 'push' and 'save'
2021-11-29Merge branch 'ab/refs-errno-cleanup'Libravatar Junio C Hamano3-1/+89
The "remainder" of hn/refs-errno-cleanup topic. * ab/refs-errno-cleanup: (21 commits) refs API: post-migration API renaming [2/2] refs API: post-migration API renaming [1/2] refs API: don't expose "errno" in run_transaction_hook() refs API: make expand_ref() & repo_dwim_log() not set errno refs API: make resolve_ref_unsafe() not set errno refs API: make refs_ref_exists() not set errno refs API: make refs_resolve_refdup() not set errno refs tests: ignore ignore errno in test-ref-store helper refs API: ignore errno in worktree.c's find_shared_symref() refs API: ignore errno in worktree.c's add_head_info() refs API: make files_copy_or_rename_ref() et al not set errno refs API: make loose_fill_ref_dir() not set errno refs API: make resolve_gitlink_ref() not set errno refs API: remove refs_read_ref_full() wrapper refs/files: remove "name exist?" check in lock_ref_oid_basic() reflog tests: add --updateref tests refs API: make refs_rename_ref_available() static refs API: make parse_loose_ref_contents() not set errno refs API: make refs_read_raw_ref() not set errno refs API: add a version of refs_resolve_ref_unsafe() with "errno" ...
2021-11-29Merge branch 'ow/stash-count-in-status-porcelain-output'Libravatar Junio C Hamano1-0/+15
Allow "git status --porcelain=v2" to show the number of stash entries with --show-stash like the normal output does. * ow/stash-count-in-status-porcelain-output: status: print stash info with --porcelain=v2 --show-stash status: count stash entries in separate function
2021-11-29Merge branch 'jk/loosen-urlmatch'Libravatar Junio C Hamano1-1/+1
Treat "_" as any other URL-valid characters in an URL when matching the per-URL configuration variable names. * jk/loosen-urlmatch: urlmatch: add underscore to URL_HOST_CHARS
2021-11-22Merge branch 'ds/add-rm-with-sparse-index'Libravatar Junio C Hamano1-0/+17
Regression fix for 2.34 * ds/add-rm-with-sparse-index: dir: revert "dir: select directories correctly"
2021-11-22dir: revert "dir: select directories correctly"Libravatar Derrick Stolee1-0/+17
This reverts commit f6526728f950cacfd5b5e42bcc65f2c47f3da654. The change in f652672 (dir: select directories correctly, 2021-09-24) caused a regression in directory-based matches with non-cone-mode patterns, especially for .gitignore patterns. A test is included to prevent this regression in the future. The commit ed495847 (dir: fix pattern matching on dirs, 2021-09-24) was reverted in 5ceb663 (dir: fix directory-matching bug, 2021-11-02) for similar reasons. Neither commit changed tests, and tests added later in the series continue to pass when these commits are reverted. Reported-by: Danial Alihosseini <danial.alihosseini@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-21Merge branch 'ev/pull-already-up-to-date-is-noop'Libravatar Junio C Hamano1-0/+6
"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date
2021-11-21Merge branch 'hm/paint-hits-in-log-grep'Libravatar Junio C Hamano1-48/+0
"git grep" looking in a blob that has non-UTF8 payload was completely broken when linked with certain versions of PCREv2 library in the latest release. * hm/paint-hits-in-log-grep: Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"
2021-11-19Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"Libravatar Junio C Hamano1-48/+0
This reverts commit ae39ba431ab861548eb60b4bd2e1d8b8813db76f, as it breaks "grep" when looking for a string in non UTF-8 haystack, when linked with certain versions of PCREv2 library. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18pull: should be noop when already-up-to-dateLibravatar Erwin Villejo1-0/+6
The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-12Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano1-0/+8
Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2
2021-11-12Merge branch 'ps/connectivity-optim'Libravatar Junio C Hamano1-31/+0
Regression fix. * ps/connectivity-optim: Revert "connected: do not sort input revisions"
2021-11-11Revert "connected: do not sort input revisions"Libravatar Junio C Hamano1-31/+0
This reverts commit f45022dc2fd692fd024f2eb41a86a66f19013d43, as this is like breakage in the traversal more likely. In a history with 10 single strand of pearls, 1-->2-->3--...->7-->8-->9-->10 asking "rev-list --unsorted-input 1 10 --not 9 8 7 6 5 4" fails to paint the bottom 1 uninteresting as the traversal stops, without completing the propagation of uninteresting bit starting at 4 down through 3 and 2 to 1.
2021-11-11object-file: fix SEGV on free() regression in v2.34.0-rc2Libravatar Ævar Arnfjörð Bjarmason1-0/+8
Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'jk/ssh-signing-fix'Libravatar Junio C Hamano1-0/+6
Reject OpenSSH 8.7 whose "ssh-keygen -Y find-principals" is unusable from running the ssh signature tests. * jk/ssh-signing-fix: t/lib-gpg: avoid broken versions of ssh-keygen
2021-11-10Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'Libravatar Junio C Hamano1-1/+15
"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date
2021-11-10t/lib-gpg: avoid broken versions of ssh-keygenLibravatar Jeff King1-0/+6
The "-Y find-principals" option of ssh-keygen seems to be broken in Debian's openssh-client 1:8.7p1-1, whereas it works fine in 1:8.4p1-5. This causes several failures for GPGSSH tests. We fulfill the prerequisite because generating the keys works fine, but actually verifying a signature causes results ranging from bogus results to ssh-keygen segfaulting. We can find the broken version during the prereq check by feeding it empty input. This should result in it complaining to stderr, but in the broken version it triggers the segfault, causing the GPGSSH tests to be skipped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09Merge branch 'ad/ssh-signing-testfix'Libravatar Junio C Hamano1-0/+1
Fix ssh-signing test to work on a platform where the default ACL is overly loose to upset OpenSSH (reported on an installation of Cygwin). * ad/ssh-signing-testfix: t/lib-git.sh: fix ACL-related permissions failure
2021-11-05t/lib-git.sh: fix ACL-related permissions failureLibravatar Adam Dinwoodie1-0/+1
As well as checking that the relevant functionality is available, the GPGSSH prerequisite check creates the SSH keys that are used by the test functions it gates. If these keys are created in a directory that has a default Access Control List, the key files can inherit those permissions. This can result in a scenario where the private keys are created successfully, so the prerequisite check passes and the tests are run, but the key files have permissions that are too permissive, meaning OpenSSH will refuse to load them and the tests will fail. To avoid this happening, before creating the keys, clear any default ACL set on the directory that will contain them. This step allowed to fail; if setfacl isn't present, that's a very likely indicator that the filesystem in question simply doesn't support default ACLs. Helped-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04Merge branch 'ar/no-verify-doc'Libravatar Junio C Hamano1-0/+8
Doc update. * ar/no-verify-doc: Document positive variant of commit and merge option "--no-verify"
2021-11-04Merge branch 'ar/fix-git-pull-no-verify'Libravatar Junio C Hamano1-0/+24
"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook
2021-11-03Merge branch 'pw/rebase-r-fixes'Libravatar Junio C Hamano1-0/+29
Regression fix. * pw/rebase-r-fixes: rebase -i: fix rewording with --committer-date-is-author-date
2021-11-03Merge branch 'ds/add-rm-with-sparse-index'Libravatar Junio C Hamano1-0/+26
Regression fix. * ds/add-rm-with-sparse-index: dir: fix directory-matching bug
2021-11-03clean/smudge: allow clean filters to process extremely large filesLibravatar Matt Cooper1-0/+11
The filter system allows for alterations to file contents when they're moved between the database and the worktree. We already made sure that it is possible for smudge filters to produce contents that are larger than `unsigned long` can represent (which matters on systems where `unsigned long` is narrower than `size_t`, most notably 64-bit Windows). Now we make sure that clean filters can _consume_ contents that are larger than that. Note that this commit only allows clean filters' _input_ to be larger than can be represented by `unsigned long`. This change makes only a very minute dent into the much larger project to teach Git to use `size_t` instead of `unsigned long` wherever appropriate. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03odb: teach read_blob_entry to use size_tLibravatar Matt Cooper1-1/+1
There is mixed use of size_t and unsigned long to deal with sizes in the codebase. Recall that Windows defines unsigned long as 32 bits even on 64-bit platforms, meaning that converting size_t to unsigned long narrows the range. This mostly doesn't cause a problem since Git rarely deals with files larger than 2^32 bytes. But adjunct systems such as Git LFS, which use smudge/clean filters to keep huge files out of the repository, may have huge file contents passed through some of the functions in entry.c and convert.c. On Windows, this results in a truncated file being written to the workdir. I traced this to one specific use of unsigned long in write_entry (and a similar instance in write_pc_item_to_fd for parallel checkout). That appeared to be for the call to read_blob_entry, which expects a pointer to unsigned long. By altering the signature of read_blob_entry to expect a size_t, write_entry can be switched to use size_t internally (which all of its callers and most of its callees already used). To avoid touching dozens of additional files, read_blob_entry uses a local unsigned long to call a chain of functions which aren't prepared to accept size_t. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03t1051: introduce a smudge filter test for extremely large filesLibravatar Matt Cooper1-0/+15
The filter system allows for alterations to file contents when they're added to the database or working tree. ("Smudge" when moving to the working tree; "clean" when moving to the database.) This is used natively to handle CRLF to LF conversions. It's also employed by Git-LFS to replace large files from the working tree with small tracking files in the repo and vice versa. Git reads the entire smudged file into memory to convert it into a "clean" form to be used in-core. While this is inefficient, there's a more insidious problem on some platforms due to inconsistency between using unsigned long and size_t for the same type of data (size of a file in bytes). On most 64-bit platforms, unsigned long is 64 bits, and size_t is typedef'd to unsigned long. On Windows, however, unsigned long is only 32 bits (and therefore on 64-bit Windows, size_t is typedef'd to unsigned long long in order to be 64 bits). Practically speaking, this means 64-bit Windows users of Git-LFS can't handle files larger than 2^32 bytes. Other 64-bit platforms don't suffer this limitation. This commit introduces a test exposing the issue; future commits make it pass. The test simulates the way Git-LFS works by having a tiny file checked into the repository and expanding it to a huge file on checkout. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Matt Cooper <vtbassmatt@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-lib: add prerequisite for 64-bit platformsLibravatar Carlo Marcelo Arenas Belón1-0/+4
Allow tests that assume a 64-bit `size_t` to be skipped in 32-bit platforms and regardless of the size of `long`. This imitates the `LONG_IS_64BIT` prerequisite. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-tool genzeros: generate large amounts of data more efficientlyLibravatar Johannes Schindelin1-2/+15
In this developer's tests, producing one gigabyte worth of NULs in a busy loop that writes out individual bytes, unbuffered, took ~27sec. Writing chunked 256kB buffers instead only took ~0.6sec This matters because we are about to introduce a pair of test cases that want to be able to produce 5GB of NULs, and we cannot use `/dev/zero` because of the HP NonStop platform's lack of support for that device. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03test-genzeros: allow more than 2G zeros in WindowsLibravatar Carlo Marcelo Arenas Belón1-2/+2
d5cfd142ec (tests: teach the test-tool to generate NUL bytes and use it, 2019-02-14), add a way to generate zeroes in a portable way without using /dev/zero (needed by HP NonStop), but uses a long variable that is limited to 2^31 in Windows. Use instead a (POSIX/C99) intmax_t that is at least 64bit wide in 64-bit Windows to use in a future test. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03rebase -i: fix rewording with --committer-date-is-author-dateLibravatar Phillip Wood1-0/+29
baf8ec8d3a (rebase -r: don't write .git/MERGE_MSG when fast-forwarding, 2021-08-20) stopped reading the author script in run_git_commit() when rewording a commit. This is normally safe because "git commit --amend" preserves the authorship. However if the user passes "--committer-date-is-author-date" then we need to read the author date from the author script when rewording. Fix this regression by tightening the check for when it is safe to skip reading the author script. Reported-by: Jonas Kittner <jonas.kittner@ruhr-uni-bochum.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-03dir: fix directory-matching bugLibravatar Derrick Stolee1-0/+26
This reverts the change from ed49584 (dir: fix pattern matching on dirs, 2021-09-24), which claimed to fix a directory-matching problem without a test case. It turns out to _create_ a bug, but it is a bit subtle. The bug would have been revealed by the first of two tests being added to t0008-ignores.sh. The first uses a pattern "/git/" inside the a/.gitignores file, which matches against 'a/git/foo' but not 'a/git-foo/bar'. This test would fail before the revert. The second test shows what happens if the test instead uses a pattern "git/" and this test passes both before and after the revert. The difference in these two cases are due to how last_matching_pattern_from_list() checks patterns both if they have the PATTERN_FLAG_MUSTBEDIR and PATTERN_FLAG_NODIR flags. In the case of "git/", the PATTERN_FLAG_NODIR is also provided, making the change in behavior in match_pathname() not affect the end result of last_matching_pattern_from_list(). Reported-by: Glen Choo <chooglen@google.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-01Merge branch 'ab/test-lib'Libravatar Junio C Hamano1-1/+0
Test (cosmetic) fix. * ab/test-lib: t5310: drop lib-bundle.sh include
2021-11-01Merge branch 'gc/use-repo-settings'Libravatar Junio C Hamano4-7/+55
It is wrong to read some settings directly from the config subsystem, as things like feature.experimental can affect their default values. * gc/use-repo-settings: gc: perform incremental repack when implictly enabled fsck: verify multi-pack-index when implictly enabled fsck: verify commit graph when implicitly enabled
2021-11-01Merge branch 'ab/ignore-replace-while-working-on-commit-graph'Libravatar Junio C Hamano2-10/+15
Teach "git commit-graph" command not to allow using replace objects at all, as we do not use the commit-graph at runtime when we see object replacement. * ab/ignore-replace-while-working-on-commit-graph: commit-graph: don't consider "replace" objects with "verify" commit-graph tests: fix another graph_git_two_modes() helper commit-graph tests: fix error-hiding graph_git_two_modes() helper
2021-11-01Merge branch 'hm/paint-hits-in-log-grep'Libravatar Junio C Hamano2-0/+99
"git log --grep=string --author=name" learns to highlight hits just like "git grep string" does. * hm/paint-hits-in-log-grep: grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data pretty: colorize pattern matches in commit messages grep: refactor next_match() and match_one_pattern() for external use
2021-10-29Merge branch 'mt/fix-add-rm-with-sparse-index'Libravatar Junio C Hamano3-5/+73
Fix-up to a topic already merged to 'master'. * mt/fix-add-rm-with-sparse-index: add, rm, mv: fix bug that prevents the update of non-sparse dirs
2021-10-29Merge branch 'jk/log-warn-on-bogus-encoding'Libravatar Junio C Hamano1-7/+0
Squelch over-eager warning message added during this cycle. * jk/log-warn-on-bogus-encoding: log: document --encoding behavior on iconv() failure Revert "logmsg_reencode(): warn when iconv() fails"
2021-10-29Merge branch 'ab/plug-random-leaks'Libravatar Junio C Hamano1-1/+2
Leakfix. * ab/plug-random-leaks: reflog: free() ref given to us by dwim_log() submodule--helper: fix small memory leaks clone: fix a memory leak of the "git_dir" variable grep: fix a "path_list" memory leak grep: use object_array_clear() in cmd_grep() grep: prefer "struct grep_opt" over its "void *" equivalent
2021-10-29Merge branch 'ab/plug-handle-path-exclude-leak'Libravatar Junio C Hamano1-0/+1
Leakfix. * ab/plug-handle-path-exclude-leak: config.c: don't leak memory in handle_path_include()
2021-10-29Merge branch 'jk/http-push-status-fix'Libravatar Junio C Hamano4-0/+27
"git push" client talking to an HTTP server did not diagnose the lack of the final status report from the other side correctly, which has been corrected. * jk/http-push-status-fix: transport-helper: recognize "expecting report" error from send-pack send-pack: complain about "expecting report" with --helper-status
2021-10-29Merge branch 'ab/test-bail'Libravatar Junio C Hamano1-7/+21
A new feature has been added to abort early in the test framework. * ab/test-bail: test-lib.sh: use "Bail out!" syntax on bad SANITIZE=leak use test-lib.sh: de-duplicate error() teardown code
2021-10-29Revert "logmsg_reencode(): warn when iconv() fails"Libravatar Junio C Hamano1-7/+0
This reverts commit fd680bc5 (logmsg_reencode(): warn when iconv() fails, 2021-08-27). Throwing a warning for each and every commit that gets reencoded, without allowing a way to squelch, would make it unpleasant for folks who have to deal with an ancient part of the history in an old project that used wrong encoding in the commits.