Pull a Patch from Raw Email with git mailinfo

Someone emailed you a patch instead of opening a pull request, and git mailinfo turns that raw message into a usable commit message and diff. By the end you will have two files made from one email: a commit message and a patch, plus the author and subject metadata Git reports for git am. The examples use Git 2.43.0 and the installed git-man documentation.

Allow about fifteen minutes. You need Git, a raw email saved as a file, and write access to a scratch directory. This is an ordinary user operation that neither applies the patch nor creates a commit, but treat the email as untrusted input and check the output before it goes anywhere near a repository.

1. Check the installed interface

Confirm the executable and version before relying on the examples. No elevated privileges needed:

$ git --version
git version 2.43.0
$ git mailinfo -h
usage: git mailinfo [options] <msg> <patch>

The command reads one message from standard input. Its two positional arguments are output paths, not input paths: the first gets the commit log text, the second the extracted patch. Git writes the author name, author email and subject to standard output.

Checkpoint: if git mailinfo -h is not available, stop and repair Git through your normal system process. Do not borrow flags from a different version.

2. Put the raw email in a scratch directory

Use a directory that is not your working tree. Replace the placeholder path with the email file you actually received:

$ work=/tmp/mailinfo-check
$ mkdir -p "$work"
$ cp /path/to/patch-email.eml "$work/message.eml"
$ test -s "$work/message.eml" && echo "input is non-empty"
input is non-empty

cp makes a disposable copy so the original stays untouched. Do not run a path supplied by an email as a shell command, and do not redirect output into a repository file until you have checked what came out.

3. Extract the message and patch

Run git mailinfo with two new output paths. The final redirection is the email input:

$ git mailinfo "$work/commit-message.txt" "$work/change.patch" \
    < "$work/message.eml" > "$work/metadata.txt"
$ printf 'status: %s\n' "$?"
status: 0

A successful run writes three outputs. Check them all before doing anything with the patch:

$ sed -n '1,20p' "$work/metadata.txt"
Author: Example Developer <[email protected]>
Subject: [PATCH] Fix the example
$ sed -n '1,40p' "$work/commit-message.txt"
Fix the example
$ sed -n '1,20p' "$work/change.patch"
From ...
diff --git a/...

Your own author, subject and patch content will come from your email. The subject normally has email cruft stripped: a leading Re:, bracketed prefixes such as [PATCH], and stray or repeated whitespace are all handled by the default mode. The patch itself is extracted separately and is not charset-converted.

4. Keep or change subject cleanup deliberately

Use -k to preserve the subject instead of letting mailinfo clean it, which matters most when you are reading output produced by git format-patch -k:

$ git mailinfo -k "$work/keep-message.txt" "$work/keep.patch" \
    < "$work/message.eml" > "$work/keep-metadata.txt"
$ sed -n '1,5p' "$work/keep-metadata.txt"

Use -b instead when the normal mode should strip only leading bracketed strings containing the word PATCH. Both switches touch subject handling, not whether a patch applies. If an extracted subject looks unexpectedly short, compare the normal and -k outputs rather than editing the patch by hand.

5. Handle replies, encodings and message IDs

If a reply carries discussion above a scissors marker, add --scissors to discard everything before it, marker included. A site-wide or user setting named mailinfo.scissors can turn this on by default; override it for one run with --no-scissors, or the reverse:

$ git -c mailinfo.scissors=false mailinfo --scissors \
    "$work/scissors-message.txt" "$work/scissors.patch" \
    < "$work/message.eml" > "$work/scissors-metadata.txt"

Metadata is minimally MIME-decoded and re-coded to i18n.commitEncoding, or UTF-8 when that is unset. That is the default in Git 2.43.0. Use --encoding=CHARSET for a specific target, or -n to switch off the re-coding entirely. Neither option touches the patch. If a mailing-list thread needs to stay traceable, -m appends the email's Message-ID to the commit message.

For quoted-printable or base64 input whose decoded lines end in CRLF, --quoted-cr=warn is the installed default unless mailinfo.quotedCR says otherwise. The other actions are nowarn and strip. Stick with the warning while you are investigating an unfamiliar message; stripping changes the decoded text.

6. Decide what happens next

git-mailinfo is a plumbing step. It does not apply change.patch, check whether it applies cleanly, or create a commit. The usual next move after reviewing the message and patch is git am, which is a genuinely state-changing action: it can modify your index and working tree and create commits. Check the repository status first, keep a recovery point, and follow your repository's normal abort procedure if applying it fails.

Nothing persistent needs undoing from the examples here. To clear only the scratch outputs, remove the exact temporary directory once you are done inspecting it:

$ rm -rf -- "$work"
$ test ! -e "$work" && echo "scratch outputs removed"
scratch outputs removed

Never run that removal against a repository or a path you have not checked. The raw email may be the only copy of the submission you have.

Done means