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

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

format-patch: allow --rfc to optionally take a value, like --rfc=WIP

2024-04-23T18:00:38Z

With the "--rfc" option, we can tweak the "[PATCH]" (or whatever string specified with the "--subject-prefix" option, instead of "PATCH") that we prefix the title of the commit with into "[RFC PATCH]", but some projects may want "[rfc PATCH]". Adding a new option, e.g., "--rfc-lowercase", to support such need every time somebody wants to use different strings would lead to insanity of accumulating unbounded number of such options. Allow an optional value specified for the option, so that users can use "--rfc=rfc" (think of "--rfc" without value as a short-hand for "--rfc=RFC") if they wanted to. This can of course be (ab)used to make the prefix "[WIP PATCH]" by passing "--rfc=WIP". Passing an empty string, i.e., "--rfc=", is the same as "--no-rfc" to override an option given earlier on the same command line. Signed-off-by: Junio C Hamano

format-patch: ensure that --rfc and -k are mutually exclusive

2024-04-19T15:40:57Z

Fix a bug that allows the "--rfc" and "-k" options to be specified together when "git format-patch" is executed, which was introduced in the commit e0d7db7423a9 ("format-patch: --rfc honors what --subject-prefix sets"). Add a couple of additional tests to t4014, to cover additional cases of the mutual exclusivity between different "git format-patch" options. Signed-off-by: Dragan Simic Signed-off-by: Junio C Hamano

format-patch: fix ignored encode_email_headers for cover letter

2023-11-10T02:04:11Z

When writing the cover letter, the encode_email_headers option was ignored. That is, UTF-8 subject lines and email addresses were written out as-is, without any Q-encoding, even if --encode-email-headers was passed on the command line. This is due to encode_email_headers not being copied over from struct rev_info to struct pretty_print_context. Fix that and add a test. Signed-off-by: Simon Ser Signed-off-by: Junio C Hamano