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

sequencer: use trailer's trailer layout

2016-11-29T22:22:18Z

Make sequencer use trailer.c's trailer layout definition, as opposed to parsing the footer by itself. This makes "commit -s", "cherry-pick -x", and "format-patch --signoff" consistent with trailer, allowing non-trailer lines and multiple-line trailers in trailer blocks under certain conditions, and therefore suppressing the extra newline in those cases. Consistency with trailer extends to respecting trailer configs. Tests have been included to show that. Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

Merge branch 'jt/format-patch-rfc'

2016-09-26T23:09:17Z

In some projects, it is common to use "[RFC PATCH]" as the subject prefix for a patch meant for discussion rather than application. A new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH" to help the participants of such projects. * jt/format-patch-rfc: format-patch: add "--rfc" for the common case of [RFC PATCH]

format-patch: add "--rfc" for the common case of [RFC PATCH]

2016-09-21T15:58:10Z

Add an alias for --subject-prefix='RFC PATCH', which is used commonly in some development communities to deserve such a short-hand. Signed-off-by: Josh Triplett Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

format-patch: show base info before email signature

2016-09-15T17:07:10Z

Any text below the "-- " for the email signature gets treated as part of the signature, and many mail clients will trim it from the quoted text for a reply. Move it above the signature, so people can reply to it more easily. Similarly, when producing the patch as a MIME attachment, the original code placed the base info after the attached part, which would be discarded. Move the base info to the end of the part, still inside the part boundary. Add tests for the exact format of the email signature, and add tests to ensure that the base info appears before the email signature when producing a plain-text output, and that it appears before the part boundary when producing a MIME attachment. Signed-off-by: Josh Triplett Signed-off-by: Junio C Hamano

Merge branch 'jt/format-patch-from-config'

2016-08-10T19:33:18Z

"git format-patch" learned format.from configuration variable to specify the default settings for its "--from" option. * jt/format-patch-from-config: format-patch: format.from gives the default for --from

format-patch: format.from gives the default for --from

2016-08-01T20:13:02Z

This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett Signed-off-by: Junio C Hamano

Merge branch 'ew/mboxrd-format-am'

2016-07-06T20:38:11Z

Teach format-patch and mailsplit (hence "am") how a line that happens to begin with "From " in the e-mail message is quoted with ">", so that these lines can be restored to their original shape. * ew/mboxrd-format-am: am: support --patch-format=mboxrd mailsplit: support unescaping mboxrd messages pretty: support "mboxrd" output format

Merge branch 'jk/shell-portability'

2016-06-10T22:26:05Z

test fixes. * jk/shell-portability: t5500 & t7403: lose bash-ism "local" test-lib: add in-shell "env" replacement

pretty: support "mboxrd" output format

2016-06-06T18:14:14Z

This output format prevents format-patch output from breaking readers if somebody copy+pasted an mbox into a commit message. Unlike the traditional "mboxo" format, "mboxrd" is designed to be fully-reversible. "mboxrd" also gracefully degrades to showing extra ">" in existing "mboxo" readers. This degradation is preferable to breaking message splitting completely, a problem I've seen in "mboxcl" due to having multiple, non-existent, or inaccurate Content-Length headers. "mboxcl2" is a non-starter since it's inherits the problems of "mboxcl" while being completely incompatible with existing tooling based around mailsplit. ref: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano

test-lib: add in-shell "env" replacement

2016-06-01T15:04:08Z

The one-shot environment variable syntax: FOO=BAR some-program is unportable when some-program is actually a shell function, like test_must_fail (on some shells FOO remains set after the function returns, and on others it does not). We sometimes get around this by using env, like: test_must_fail env FOO=BAR some-program But that only works because test_must_fail's arguments are themselves a command which can be run. You can't run: env FOO=BAR test_must_fail some-program because env does not know about our shell functions. So there is no equivalent for test_commit, for example, and one must resort to: ( FOO=BAR export FOO test_commit ) which is a bit verbose. Let's add a version of "env" that works _inside_ the shell, by creating a subshell, exporting variables from its argument list, and running the command. Its use is demonstrated on a currently-unportable case in t4014. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano