revisions API: have release_revisions() release "cmdline"

2022-04-14T06:56:09Z

Extend the the release_revisions() function so that it frees the "cmdline" in the "struct rev_info". This in combination with a preceding change to free "commits" and "mailmap" means that we can whitelist another test under "TEST_PASSES_SANITIZE_LEAK=true". There was a proposal in [1] to do away with xstrdup()-ing this add_rev_cmdline(), perhaps that would be worthwhile, but for now let's just free() it. We could also make that a "char *" in "struct rev_cmdline_entry" itself, but since we own it let's expose it as a constant to outside callers. I proposed that in [2] but have since changed my mind. See 14d30cdfc04 (ref-filter: fix memory leak in `free_array_item()`, 2019-07-10), c514c62a4fd (checkout: fix leak of non-existent branch names, 2020-08-14) and other log history hits for "free((char *)" for prior art. This includes the tests we had false-positive passes on before my 6798b08e848 (perl Git.pm: don't ignore signalled failure in _cmd_close(), 2022-02-01), now they pass for real. Since there are 66 tests matching t/t[0-9]*git-svn*.sh it's easier to list those that don't pass than to touch most of those 66. So let's introduce a "TEST_FAILS_SANITIZE_LEAK=true", which if set in the tests won't cause lib-git-svn.sh to set "TEST_PASSES_SANITIZE_LEAK=true. This change also marks all the tests that we removed "TEST_FAILS_SANITIZE_LEAK=true" from in an earlier commit due to removing the UNLEAK() from cmd_format_patch(), we can now assert that its API use doesn't leak any "struct rev_info" memory. This change also made commit "t5503-tagfollow.sh" pass on current master, but that would regress when combined with ps/fetch-atomic-fixup's de004e848a9 (t5503: simplify setup of test which exercises failure of backfill, 2022-03-03) (through no fault of that topic, that change started using "git clone" in the test, which has an outstanding leak). Let's leave that test out for now to avoid in-flight semantic conflicts. 1. https://lore.kernel.org/git/YUj%2FgFRh6pwrZalY@carlos-mbp.lan/ 2. https://lore.kernel.org/git/87o88obkb1.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Convert "! git" to "test_must_fail git"

2010-07-20T23:47:17Z

test_must_fail will account for segfaults in git, so it should be used instead of "! git" This patch does not change any of the commands that use pipes. Signed-off-by: Jared Hance Signed-off-by: Junio C Hamano

t9139 uses ancient, backwards-compatible iconv names

2009-05-31T05:30:55Z

This resolves a semantic conflicts early to work with 5ae93df (t3900: use ancient iconv names for backward compatibility, 2009-05-18). Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano

git-svn: refuse to dcommit non-UTF-8 messages

2009-05-28T07:57:07Z

...without i18n.commitencoding set in the config. SVN tries to store all commit messages in UTF-8, however it is up to the job of the clients to enforce this rule. SVN servers themselves do not always enforce this; allowing clients to commit malformed UTF-8 messages and break repositories. So git-svn will enforce this and tell the user to set i18n.commitencoding when a git commit is is not in UTF-8. Signed-off-by: Eric Wong

git/t/t9139-git-svn-non-utf8-commitencoding.sh, branch v2.43.3

revisions API: have release_revisions() release "cmdline"

Convert "! git" to "test_must_fail git"

t9139 uses ancient, backwards-compatible iconv names

git-svn: refuse to dcommit non-UTF-8 messages