git/t/t4014-format-patch.sh, branch v2.51.2

t: introduce PERL_TEST_HELPERS prerequisite

2025-04-07T21:47:37Z

In the early days of Git, Perl was used quite prominently throughout the project. This has changed significantly as almost all of the executables we ship nowadays have eventually been rewritten in C. Only a handful of subsystems remain that require Perl: - gitweb, a read-only web interface. - A couple of scripts that allow importing repositories from GNU Arch, CVS and Subversion. - git-send-email(1), which can be used to send mails. - git-request-pull(1), which is used to request somebody to pull from a URL by sending an email. - git-filter-branch(1), which uses Perl with the `--state-branch` option. This command is typically recommended against nowadays in favor of git-filter-repo(1). - Our Perl bindings for Git. - The netrc Git credential helper. None of these subsystems can really be considered to be part of the "core" of Git, and an installation without them is fully functional. It is more likely than not that an end user wouldn't even notice that any features are missing if those tools weren't installed. But while Perl nowadays very much is an optional dependency of Git, there is a significant limitation when Perl isn't available: developers cannot run our test suite. Preceding commits have started to lift this restriction by removing the strict dependency on Perl in many central parts of the test library. But there are still many tests that rely on small Perl helpers to do various different things. Introduce a new PERL_TEST_HELPERS prerequisite that guards all tests that require Perl. This prerequisite is explicitly different than the preexisting PERL prerequisite: - PERL records whether or not features depending on the Perl interpreter are built. - PERL_TEST_HELPERS records whether or not a Perl interpreter is available for our tests. By having these two separate prerequisites we can thus distinguish between tests that inherently depend on Perl because the underlying feature does, and those tests that depend on Perl because the test itself is using Perl. Adapt all tests to set the PERL_TEST_HELPERS prerequisite as needed. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

t: remove TEST_PASSES_SANITIZE_LEAK annotations

2024-11-20T23:23:48Z

Now that the default value for TEST_PASSES_SANITIZE_LEAK is `true` there is no longer a need to have that variable declared in all of our tests. Drop it. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

builtin/format-patch: fix various trivial memory leaks

2024-08-14T17:08:01Z

There are various memory leaks hit by git-format-patch(1). Basically all of them are trivial, except that un-setting `diffopt.no_free` requires us to unset the `diffopt.file` because we manually close it already. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'rj/format-patch-auto-cover-with-interdiff'

2024-06-20T22:45:12Z

"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

format-patch: assume --cover-letter for diff in multi-patch series

2024-06-07T21:02:13Z

When we deal with a multi-patch series in git-format-patch(1), if we see `--interdiff` or `--range-diff` but no `--cover-letter`, we return with an error, saying: fatal: --range-diff requires --cover-letter or single patch or: fatal: --interdiff requires --cover-letter or single patch This makes sense because the cover-letter is where we place the diff from the previous version. However, considering that `format-patch` generates a multi-patch as needed, let's adopt a similar "cover as necessary" approach when using `--interdiff` or `--range-diff`. Therefore, relax the requirement for an explicit `--cover-letter` in a multi-patch series when the user says `--iterdiff` or `--range-diff`. Still, if only to return the error, respect "format.coverLetter=no" and `--no-cover-letter`. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

t4014: cleanups in a few tests

2024-06-07T21:02:12Z

Arrange things we are going to create to be removed at end, and then start creating them. That way, we will clean them up even if we fail after creating some but before the end of the command. Signed-off-by: Rubén Justo Signed-off-by: Junio C Hamano

format-patch: move range/inter diff at the end of a single patch output

2024-05-24T23:26:57Z

When running "format-patch" on a multiple patch series, the output coming from "--interdiff" and "--range-diff" options is inserted after the "shortlog" list of commits and the overall diffstat. The idea is that shortlog/diffstat are shorter and with denser information content, which gives a better overview before the readers dive into more details of range/inter diff. When working on a single patch, however, we stuff the inter/range diff output before the actual patch, next to the diffstat. This pushes down the patch text way down with inter/range diff output, distracting readers. Move the inter/range diff output to the very end of the output, after all the patch text is shown. As the inter/range diff is no longer part of the commentary block (i.e., what comes after the log message and "---", but before the patch text), stop producing "---" in the function that generates them. But to separate it out visually (note: this is not needed to help tools like "git apply" that pay attention to the hunk headers to figure out the length of the hunks), add an extra blank line between the end of the patch text and the inter/range diff. Signed-off-by: Junio C Hamano

Merge branch 'jc/format-patch-rfc-more'

2024-04-30T21:49:43Z

The "--rfc" option of "git format-patch" learned to take an optional string value to be used in place of "RFC" to tweak the "[PATCH]" on the subject header. * jc/format-patch-rfc-more: format-patch: "--rfc=-(WIP)" appends to produce [PATCH (WIP)] format-patch: allow --rfc to optionally take a value, like --rfc=WIP

Merge branch 'ds/format-patch-rfc-and-k'

2024-04-30T21:49:42Z

The "-k" and "--rfc" options of "format-patch" will now error out when used together, as one tells us not to add anything to the title of the commit, and the other one tells us to add "RFC" in addition to "PATCH". * ds/format-patch-rfc-and-k: format-patch: ensure that --rfc and -k are mutually exclusive

format-patch: "--rfc=-(WIP)" appends to produce [PATCH (WIP)]

2024-04-23T18:00:39Z

In the previous step, the "--rfc" option of "format-patch" learned to take an optional string value to prepend to the subject prefix, so that --rfc=WIP can give "[WIP PATCH]". There may be cases in which the extra string wants to come after the subject prefix. Extend the mechanism to allow "--rfc=-(WIP)" [*] to signal that the extra string is to be appended instead of getting prepended, resulting in "[PATCH (WIP)]". In the documentation, discourage (ab)using "--rfc=-RFC" to say "[PATCH RFC]" just to be different, when "[RFC PATCH]" is the norm. [Footnote] * The syntax takes inspiration from Perl's open syntax that opens pipes "open fh, '|-', 'cmd'", where the dash signals "the other stuff comes here". Signed-off-by: Junio C Hamano