stg-email - Man Page

Use <branch> instead of current branch

Format all applied patches

Pass additional <option> to git format-patch.

See the git-format-patch(1) man page. This option may be specified multiple times.

Use <dir> to store the output files instead of the current working directory.

In addition to the patches, generate a cover letter file containing the branch description, shortlog and the overall diffstat. You can fill in a description in the file before sending it out.

Use [PATCH n/m] even with a single patch

Use [PATCH] even with multiple patches

Start numbering at <n> instead of 1

Mark the series as the <n>-th iteration of the topic. The output filenames have "v<n>" prepended to them, and the subject prefix ("PATCH" by default, but configurable via the --subject-prefix option) has ` v<N>` appended to it. E.g. --reroll-count=4 may produce v4-0001-add-makefile.patch file that has "Subject: [PATCH v4 1/20] Add makefile" in it. <N> does not have to be an integer (e.g. --reroll-count=4.4, or --reroll-count=4rev2 are allowed), but the downside of using such a reroll-count is that the range-diff/interdiff with the previous version does not state exactly which version the new iteration is compared against.

Alias for --subject-prefix="RFC PATCH". RFC means "Request For Comments"; use this when sending an experimental patch for discussion rather than application.

Instead of the standard [PATCH] prefix in the subject line, instead use [<prefix>]. This allows for useful naming of a patch series, and can be combined with the --numbered option.

Do not print the names of the generated files

Add a Signed-off-by trailer to the commit message, using the committer identity of yourself. See the signoff option in git-commit(1) for more information.

Output file names will be a simple number sequence without the default first line of the commit appended.

Instead of using .patch as the suffix for generated filenames, use specified suffix. A common alternative is --suffix=.txt. Leaving this empty will remove the .patch suffix.

Do not strip/add [PATCH] from the first line of the commit log message.

Do not output contents of changes in binary files, instead display a notice that those files changed. Patches generated using this option cannot be applied properly, but they are still useful for code review.

Output an all-zero hash in each patch’s From header instead of the hash of the commit.

Add a To: header to the email headers. This is in addition to any configured headers, and may be used multiple times. The negated form --no-to discards all To: headers added so far (from config or command line).

Discard all To: addresses added so far from config or command line.

Add a Cc: header to the email headers. This is in addition to any configured headers, and may be used multiple times. The negated form --no-cc discards all Cc: headers added so far (from config or command line).

Discard all Cc: addresses added so far from config or command line.

Make the first mail (or all the mails with --no-thread) appear as a reply to the given <message-id>, which avoids breaking threads to provide a new patch series.

Add an arbitrary header to the email headers. This is in addition to any configured headers, and may be used multiple times. For example, --add-header="Organization: git-foo".

Create multipart/mixed attachment, the first part of which is the commit message and the patch itself in the second part, with Content-Disposition: attachment.

Create multipart/mixed attachment, the first part of which is the commit message and the patch itself in the second part, with Content-Disposition: inline.

Controls addition of In-Reply-To and References headers to make the second and subsequent mails appear as replies to the first. Also controls generation of the Message-ID header to reference.

The optional <style> argument can be either shallow or deep. shallow threading makes every mail a reply to the head of the series, where the head is chosen from the cover letter, the --in-reply-to, and the first patch mail, in this order. deep threading makes every mail a reply to the previous one.

The default is --no-thread, unless the format.thread configuration is set. If --thread is specified without a style, it defaults to the style specified by format.thread if any, or else shallow.

Beware that the default for git send-email is to thread emails itself. If you want git format-patch to take care of threading, you will want to ensure that threading is disabled for git send-email.

Disable message threading

Add a signature string to each email. The default signature is the git version number, or the format.signature configuration value, if specified. The signature may be disabled with --no-signature

Do not add a signature to each email

Like --signature except the signature is read from a file.

See the BASE TREE INFORMATION section of git-format-patch(1).

Show progress reports on stderr as patches are generated.

As a reviewer aid, insert an interdiff into the cover letter, or as commentary of the lone patch of a 1-patch series, showing the differences between the previous version of the patch series and the series currently being formatted. <rev> is a single revision naming the tip of the previous series which shares a common base with the series being formatted (for example git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2).

As a reviewer aid, insert a range-diff (see git-range-diff(1)) into the cover letter, or as commentary of the lone patch of a single-patch series, showing the differences between the previous version of the patch series and the series currently being formatted. <refspec> can be a single revision naming the tip of the previous series if it shares a common base with the series being formatted (for example git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2), or a revision range if the two versions of the series are disjoint (for example git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2).

Note that diff options passed to the command affect how the primary product of format-patch is generated, and they are not passed to the underlying range-diff machinery used to generate the cover-letter material (this may change in the future).

Used with --range-diff, tweak the heuristic which matches up commits between the previous and current series of patches by adjusting the creation/deletion cost fudge factor. See git-range-diff(1)) for details.

Use <branch> instead of current branch

Send all applied patches

Pass additional <option> to git send-email.

See the git-send-email(1) man page. This option may be specified multiple times.

Specify the sender of the emails. If not specified on the command line, the value of the sendemail.from configuration option is used. If neither the command-line option nor sendemail.from are set, then the user will be prompted for the value. The default for the prompt will be the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not set, as returned by git var -l.

Specify the primary recipient of the emails generated. Generally, this will be the upstream maintainer of the project involved. Default is the value of the sendemail.to configuration value; if that is unspecified, and --to-cmd is not specified, this will be prompted for.

This option may be specified multiple times.

Specify a starting "Cc:" value for each email. Default is the value of sendemail.cc.

This option may be specified multiple times.

Specify a starting "Bcc:" value for each email. Default is the value of sendemail.bcc.

This option may be specified multiple times.

Specify the initial subject of the email thread. Only necessary if --compose is also set. If --compose is not set, this will be prompted for.

Specify the address where replies from recipients should go to. Use this if replies to messages should go to another address than what is specified with the --from parameter.

Make the first mail (or all the mails with --no-thread) appear as a reply to the given Message-ID, which avoids breaking threads to provide a new patch series. The second and subsequent emails will be sent as replies according to the --[no-]chain-reply-to setting.

So for example when --thread and --no-chain-reply-to are specified, the second and subsequent patches will be replies to the first one like in the illustration below where [PATCH v2 0/3] is in reply to [PATCH 0/2]:

[PATCH 0/2] Here is what I did...
  [PATCH 1/2] Clean up and tests
  [PATCH 2/2] Implementation
  [PATCH v2 0/3] Here is a reroll
    [PATCH v2 1/3] Clean up
    [PATCH v2 2/3] New tests
    [PATCH v2 3/3] Implementation

Only necessary if --compose is also set. If --compose is not set, this will be prompted for.

Invoke a text editor (see GIT_EDITOR in git-var(1)) to edit an introductory message for the patch series.

When --compose is used, git send-email will use the From, Subject, and In-Reply-To headers specified in the message. If the body of the message (what you type after the headers and a blank line) only contains blank (or Git: prefixed) lines, the summary will not be sent, but From, Subject, and In-Reply-To headers will be used unless they are removed.

Missing From or In-Reply-To headers will be prompted for.

See the CONFIGURATION section of git-send-email(1) for sendemail.multiEdit.

Review and edit each patch you are about to send. Default is the value of sendemail.annotate.

A configuration identity. When given, causes values in the sendemail.<identity> subsection to take precedence over values in the sendemail section. The default identity is the value of sendemail.identity.

If threading is enabled, the In-Reply-To and References headers will be added to each email sent. Whether each mail refers to the previous email (deep threading per git format-patch wording) or to the first email (shallow threading) is governed by --[no-]chain-reply-to.

If disabled with --no-thread, those headers will not be added (unless specified with --in-reply-to). Default is the value of the sendemail.thread configuration value; if that is unspecified, default to --thread.

It is up to the user to ensure that no In-Reply-To header already exists when git send-email is asked to add it (especially note that git format-patch can be configured to do the threading itself). Failure to do so may not produce the expected result in the recipient’s MUA.

Confirm just before sending.

Default is the value of sendemail.confirm configuration value; if that is unspecified, default to auto unless any of the suppress options have been specified, in which case default to compose.

Confirmation modes:

• always will always confirm before sending
• never will never confirm before sending
• cc will confirm before sending when send-email has automatically added addresses from the patch to the Cc list
• compose will confirm before sending the first message when using --compose
• auto is equivalent to cc + compose

Make git-send-email less verbose. One line per email should be all that is output.

Do everything except actually send the emails.

Dump configured aliases and exit

Use [PATCH n/m] even with a single patch

Use [PATCH] even with multiple patches

Start numbering at <n> instead of 1

Mark the series as the <n>th reroll

Use [RFC PATCH] instead of [PATCH]

Use [<prefix>] instead of [PATCH]