cover letter git send email

• Page History

NOTE: Gitlab merge requests are now the strongly preferred method for submitting patches. Instructions on creating a merge request can be found in the Gitlab documentation .

How to Use git send-email

Installing send-email.

You probably already have git already installed, but that's not necessarily enough to have also the send-email command available. You can check if send-email is available by running "git send-email --help". If it shows the man page for send-email, then send-email is available. Otherwise, you need to install the send-email command. Your distribution probably has a package for it; on Debian the package name is "git-email".

Configuring Your Name and Email Address

You should tell git your name and email address. You have probably done this already, but if not, run these commands:

Configuring the Mail Sending Options

git send-email sends the emails through your SMTP server, so you need to configure the server parameters. Refer to your email provider documentation to find the right parameters. This is how I would configure my mail settings:

Storing the password in the git configuration file is obviously a security risk. It's not mandatory to configure the password. If it's not configured, git send-email will ask it every time the command is used.

Configuring the Default Destination Address

For PulseAudio, the patches should be sent to our mailing list. In order to avoid having to remember it and retyping it all the time, you can configure the address to be used by default by git send-email. As you may contribute to many projects using git, it does not make sense to set this option globally so instead we'll only set it in our clone of the PulseAudio code.

Avoiding sending mail to yourself

By default, git send-email will add the author of the patch to the Cc: field. When you send patches that you have written yourself, this means that a copy of each patch will be sent to your email address. If you don't like this, you can avoid this by setting this configuration option (see "git send-email --help" for the full list of possible values):

Using the send-email Command

See "git send-email --help" for the full reference. I'll go through only the basic usage here.

git send-email will ask a few questions before the patches are sent (update: newer git versions ask fewer questions, sometimes no questions at all). Most of the questions have a sensible default value shown in square brackets. Just press enter to use the default value. Type the answer to the question if you don't want to use the default answer. The questions are:

• This will be used as the "From" header. You should have configured your name and email address earlier, so the default is usually correct.
• As noted above, patches should be sent to our mailing list: [email protected]
• This should usually be left empty. Don't send patches as replies to regular discussion, that makes it harder to keep track of the patches.
• The mail headers are visible above the question, so that you can check that everything looks OK.

Sending a Single Patch

Sending the last commit in the current branch:

Sending some other commit:

Sending Multiple Patches

Sending the last 10 commits in the current branch:

The --cover-letter option creates an extra mail that will be sent before the actual patch mails. You can add write some introduction to the patch set in the cover letter. If you need to explain the patches, be sure to include the explanations also in the commit messages, because the cover letter text won't be recorded in the git history. If you don't think any introduction or explanation is necessary, it's fine to only have the shortlog that is included in the cover letter by default, and only set the "Subject" header to something sensible.

The --annotate option causes an editor to be started for each of the mails, allowing you to edit the mails. The option is always necessary, so that you can edit the cover letter's "Subject" header.

Adding Patch Version Information

By default the patch mails will have "[PATCH]" in the subject (or "[PATCH n/m]", where n is the sequence number of the patch and m is the total number of patches in the patch set). When sending updated versions of patches, the version should be indicated: "[PATCH v2]" or "[PATCH v2 n/m]". To do this, use the -v option. Here's an example (you may want to add --annotate to add notes to the patch about what changed in the new version):

Changing or amending the [PATCH] tag in the subject

The default "[PATCH]" tag can be changed with --subject-prefix. This is useful especially when sending pavucontrol or paprefs patches, because the subject should note when the patch is meant for some other git repository than the main pulseaudio repository. For example:

Adding Extra Notes to Patch Mails

Sometimes it's convenient to annotate patches with some notes that are not meant to be included in the commit message. For example, one might want to write "I'm not sure if this should be committed yet, because..." in a patch, but the text doesn't make sense in the commit message. Such messages can be written below the three dashes "---" that are in every patch after the commit message. Use the --annotate option with git send-email to be able to edit the mails before they are sent.

Formatting and sending in two steps

Instead of using the --annotate option, one can first run "git format-patch" to create text file(s) (with the -o option to select a directory where the text files are stored). These files can be inspected and edited, and when that is done, one can then use "git send-email" (without the -1 option) to send them.

FLUSP - FLOSS at USP

Sending patches by email with git, written by matheus tavares.

If you are a newcomer in the kernel or git development community (or others), you may find it odd that contributions aren’t sent via fancy user interfaces such as the ones provided by Github ( Pull Requests ) and Gitlab ( Merge Request ). All patches, as they are called, are sent by email to the respective mailing list.

Ok, so you got your first commit and you already figured out whom to send it to, now how do you send it? Some email clients insert html code and convert tabs to whitespaces, to make the text prettier. And that, as a result, messes up with the code you are trying to send :( So some good options are: neomutt (a terminal based email client) or git send-email ! Yes, git can send your patches! In this tutorial, we are going to see a little step-by-step guide on how to set up and use git send-email to send a single patch and patchsets.

Most of what I’ll show comes from here . I encourage you to take a look there too. Also, if you are, indeed, starting to make patches for the kernel, you may find the patch philosophy , the first kernel patch post and how to write good commit messages very useful.

Without further ado, let’s get to it!

Note: This section is for reference only. There are several nuances of setting up and using git-send-email. So read the tutorial completely.

Setting it up

1) instalation.

You probably already have git installed (if not, that’s the first thing), but depending on your distro, you may need some additional packages. In ubuntu, for example, you need git-email , in Manjaro you need perl-io-socket-ssl and perl-net-ssleay and in Arch you need perl-authen-sasl .

2) If you haven’t told git your name and email yet, do that:

Note: use you full name (or at least partial) here. For example, “Johnathan F. Hanks” and “Michael Stuart” are ok. But “Johnathan” and “Stuart” are not.

3) Configure the sending email SMTP server:

For this section, you may have to check some values depending on your email service. For gmail, for example, the SMTP server address is smtp.gmail.com and the port is 587 . Also, note that, for gmail, you will have to allow less secure apps . You can do that here . Another option is to sign in using app passwords , but I haven’t tried that.

You can also set your email password with:

But that will store your password as plain text at ~/.gitconfig , so I don’t recommend it. If you don’t set your password, you will be asked for it when you try to send an email.

4) [Optional] Supress yourself in cc:

By default, git will add the author of the commit(s) to cc. This means that when you are the author, you will send the email to yourself too. To suppress this behavior (of sending to yourself), run:

How to use it

You can send patches by different means. You can use git format-patch to write the patch to a file and then send this file using git send-email . Another option is to let git send-email deal with both patch formatting and sending (which I personally prefer).

1) Basic usage:

If you want to send your last N patches run:

If you want to send the commits from hash d2901 to hash 89e73 :

You can specify who to send the emails to with --to and --cc , but if you don’t use them, git will prompt you the recipient.

2) A more complete/real usage:

There is a lot of other useful options, and you can check them all with a man git-send-email , but what I usually use, for a single patch, is this:

And for a patchset (i.e. a series of patches), is something like this:

The options used are:

• --annotate : open the emails in your text editor to be edited/annotated before sending. Even when you won’t make any annotations, this is an excellent option to use so that you can do a final check in the patch before sending.
• --cover-letter : make a cover letter, where you can explain the overall modifications your patches make. Useful when you are sending more than one patch.
• --thread : send all the emails in the same thread, either making each one a reply to the last one or making all replying to the first one (the cover letter, if you used --cover-letter ). You can specify which behavior you want with the --[no-]chain-reply-to option.
• --[no-]chain-reply-to : use no- if you want all the emails to reply the first one (the expected behavior when sending emails to linux kernel).

More tips on patch sending

1) dry-run: a safe way to test send-email.

You can use the --dry-run option to make git-send-email do all the process but without actually sending the emails. It’s a good option to test everything before sending. You can see in the command’s output, for example, if all the people you desired to be at TO or CC really got there.

2) Prefixing emails’ subjects

Numbering When sending a patchset, the subject of each email, which will be each commits’ message title, will already be prefixed with a [PATCH 1/N], [PATCH 2/N] and so on.

Versioning When you receive a review for your patch, you’ll probably want to send a new modified version. In this case you can use a -v2 (or -v3 , and so on), in order to make git send-email prefix the email subjects with [PATCH v2 X/N].

Custom prefix You can also change the default “PATCH” in the prefix with --subject-prefix="<your_prefix_here>"

3) Annotating the patch

Sometimes you want to add comments to your patch that are not meant to be in the final patch message. For example, a comment saying “This patch depends on patch XYZ” or a patch version comment. To do that, you may use the --annotate option, which will open the email in the set editor to be edited before sending.

The --annotate option can also be used so that one can do a final check in the patch and email before sending (which is always very nice :)

Note about patch version comments Usually, when sending a v2, v3, etc., it’s good to add comments explaining the modifications made, like this:

The --- is called “scissors separator”. Eveything you add below it, until the beginning of the diff, will be ignored when applying the patch to a git repository. That’s the place to add any comment.

4) A note about patchsets and cover letter

Patchsets are series of patches sent each one in its own email. It is common to send an extra mail before the patch mails with a little abstract introducing them. This email is called cover letter, and usually it usually takes the index 0 in the series. To make a cover letter, just use the --cover-letter option. Tip: take a look at mailing list archives to see how contributors usually write cover letters.

All the following email patches in a patchset should be a reply to the first email (which usually is the cover letter). To make git do that, you must use the options --thread --no-chain-reply-to .

5) The editor set for git

You can configure which editor git will open when using the --annotate option, editing a commit message and everything that needs and editor. One way of doing that is by running:

But git also supports the standardized VISUAL and EDITOR environment variables, so you can run these commands in your bash:

Note: The above command will set the editor for git and other programs that follow these environment variables standards.

ADVERTISEMENT

Coding Essentials Guidebook for Developers

This book covers core coding concepts and tools. It contains chapters on computer architecture, the Internet, Command Line, HTML, CSS, JavaScript, Python, Java, SQL, Git, and more.

Learn more!

Decoding Git Guidebook for Developers

This book dives into the initial commit of Git's C code in detail to help developers learn what makes Git tick. If you're curious how Git works under the hood, you'll enjoy this.

Decoding Bitcoin Guidebook for Developers

This book dives into the initial commit of Bitcoin's C++ code. The book strives to unearth and simplify the concepts that underpin the Bitcoin software system, so that beginner and intermediate developers can understand how it works.

Subscribe to be notified when we release new content and features!

Follow us on your favorite channels!

git send-email | Send a patch by email in Git

Table of Contents

Introduction, use git format-patch before emailing, how do i email from git, how to use git send-email, configure git send email, git send-email examples, git send multiple patches to one recipient, git mail patch to multiple recipients (cc or bcc).

Git is a flexible version control system that offers developers various ways to work as a team. Although most dev teams share their code changes by Git pushing and Git pulling from a centralized repository, some teams choose to share their changes over email right from the command-line.

Most notably, the core Git developers and community maintain an official public Git mailing list for collaboration on Git software itself. The Linux community maintains a similar Linux kernel mailing list archive.

Before sending code changes via email, the specific changes need to be prepared for email transfer in a way that Git can understand. This is done by creating patches using the git format-patch command.

If you aren't familiar with Git patches, we highly recommend reading our post on how to create a patch in Git before continuing this article on emailing patches.

As a reminder, a Git patch is just a file that stores the changes in a commit - basically the git diff of the commit with its parent - in a text format that can be easily sent via email.

Once you have created your Git patch series (one or more Git patch files), you are ready to send them using the git send-email command.

The git send-email command can be used to send a single patch or multiple patch files from your local machine to a recipient. The main recipient is often a project mailing list, but individual developers who are involved are often CC'd.

You can also always share patches directory with a colleague for review in a less formal setting.

By default, git format-patch creates one or more patch files in the current directory, which often coincides with your project root directory, which is tracked by Git.

Be careful not to accidentally commit your patches. It's usually a good idea to add *.patch into your .gitignore file.

If patches are created in your current directory, you can simply specify them as arguments to git send-email , as we'll see in a minute.

If patches are created in their own directory, which is generally a good idea to keep them separated from your other code files and other patch sets, the entire directory can be specified.

Let's start with a few simple examples.

Git send-email has a variety of configuration options that you'll need to set in order to relay mail. It is common practice to add these into the logged-in user's git config file, located at ~/.gitconfig :

Here is a brief explanation of each of these four properties:

• smtpEncryption=tls : smtpEncryption tells Git to Transport Layer Security (TLS) to encrypt outgoing mail
• smtpServer : smtpServer tells Git which email server or service to use for mail relay
• smtpUser : smtpUser is your source email address for the mail that Git sends
• smtpServerPort : smtpServerPort is the email service port to use for mail relay

Note that the example above assumes you want to relay your Git emails through your gmail account. If you use a different email service, you'll need to determine the correct values to use. In addition, there are many more Git mail properties to work with.

More details about Git send-email configuration be found on the [git send-email docs].

The simplest way to use git send-email is to send a single patch to one recipient:

Note that the recipient email address is specified in the --to parameter, and the name of the patch file, in this case 0001-Add-readme.patch is supplied after that.

Once you hit , you'll see output similar to the following in your terminal:

This output gives you important information about your email, and asks you if you really want to send the email or not.

Important lines to pay attention to are:

• The FROM: and TO: fields: Verify these are correct before sending.
• The SUBJECT field: Verify that the subject is correct before sending.
• The Message-Id header: Used by the recipient mailbox to keep related messages together.

These fields are populated automatically from a combination of the patch file email headers, and the parameters supplied to the git send-email command.

Once everything looks good, you can typer y and hit ENTER to send, or press n followed by ENTER to cancel and return to the command-line.

As the output states, you can suppress some of Git's extra information by tweaking the git config senderemail.confirm:

To send multiple patches to one recipient just list all patches in the command as follows:

Keep in mind when sending multiple patches, the git send-email output will prompt you to send or cancel each one in a separate email.

If you used the git format-patch -o directory/ option to create your patches in a new empty directory, you can send all patches in that directory like this:

This will also prompt you to send each patch as a separate email.

Git send-email uses a consistent Message-ID header in your emails so that to recipient mailbox can link together multiple patches that were sent together in this way. You will see this Message-ID header when prompted by git send-email.

Similar to the git send-mail --to flag, you can use the --cc or --bcc flags to add additional recipients to your Git emails:

Note that Git will prioritize any command line arguments supplied to git send-email over those on the patch files. Non-conflicting parameters will simply both be applied, for example if there is a CC line in the patch file and the --cc option is used as well.

In this article, we covered what you need to known about sending email using Git, specifically relaying patches using the git send-email command.

We mentioned why you might want to collaborate via email, showed how to configure your local machine to send mail, and explained how to use the git send-email command to mail one or more patches to other devs on your team.

If you're interested in learning more about how Git works under the hood, check out our Decoding Git Guidebook for Developers , which dives into Git's code in an accessible way. We wrote it for curious developers to learn how Git works at the code level . To do this, we documented the first version of Git's code and discuss it in detail.

We hope you enjoyed this post! Feel free to shoot me an email at [email protected] with any questions or comments.

• Official Git mailing list - https://lore.kernel.org/git/
• Git-scm: git send-email docs - https://git-scm.com/docs/git-send-email

Final Notes

Recommended product: Decoding Git Guidebook for Developers

Related Articles

Git bisect | how to use git bisect.

Git Diff – What is it, Uses & Applications

Git clone | how to clone a repo in git, how to file a bug report in git, git push | pushing changes to a remote repository, git format-patch | create a patch in git, get the first 4 chapters of our decoding git guidebook for developers free , learn how git's code works... 🚀👨‍💻📚.

Check out our Decoding Git Guidebook for Developers

How I Learned to Love the Email Patch Developer Workflow

May 22, 2019

Note: This post is adapted in part from my guide to contributing to the Git project, which you can read here . I owe my thanks to my reviewers there, including Junio C. Hamano, Johannes Schindelin, Jonathan Tan, Josh Steadmon, and Phil Hord.

Five weeks ago, I joined a new team at Google, and began contributing to a new project: Git . I was (and still am) thrilled to be working on a piece of software used by countless developers across the globe! To gain a deep knowledge of a tool I’ve evangelized for so long!

But then I subscribed to the mailing list, and it truly began to sink in to me that for the forseeable future, I could expect my mailbox to look something like this:

Out of My Element

When I started writing code professionally, I worked on a team that used Gerrit. I liked it well enough that I continued to recommend it when asked; an iterative review UI based on Git, who could ask for more? At my next company, code reviews were performed by another developer examining your ClearCase checkout and sending you an email about it (yikes). Later I was asked to evaluate Team Foundation Server’s built-in review tooling for another company, on a team which insisted that “code reviews take valuable developer time” - and, as a result, generally didn’t perform them. Then I was lucky to fall back into a team using Git alongside a proprietary review tool, and then, back to my roots: Git and Gerrit on OpenBMC , and Gerrit for our internal fork, too.

This whole time, I figured no matter how bad the review process was, at least it wasn’t emailed patches. Why does anybody still use that terrible workflow? Who would want to review a diff line-by-line in their email client?!

I was envisioning someone painstakingly copying a diff from an email body and pasting it into apply . Or carefully making a second copy of the altered file and running diff -u , and then handwriting the subject and commit message.

Of course, nobody does that. It’s absolutely true that no developer today - let alone the bash-happy Unix devs of yesteryear - would use that workflow. With some tooling and good practices, I found a workflow that I love - and found myself arguing in defense of emailed patches!

git format-patch to the Rescue

Perhaps unsurprisingly, since the Git project itself is organized via emailed patches, Git has some excellent built-in tooling for preparing your commits for the inbox. git format-patch is the most notable - with it you can prepare an entire branch for mailing, include a cover letter, indicate a Request for Comment change, generate updated v2 or later patches, and more.

It’s easiest to use git format-patch if you’ve been working in a feature branch (which you always do, right..?) - for the purposes of the tutorial, we’ll assume the main branch of the project is master and your feature branch is feature ; we’ll also assume that feature has been recently rebased onto the tip of master .

Preparing a Single Patch

Imagine that you’ve got only one commit in your feature branch. Typically projects like to see individual patches sent as a single email with no cover, with a subject like “[PATCH] component: my great feature”. Make sure that your working tree is clean - that is, everything you want committed is committed - and run the following.

That’s it! -o feature-patches/ tells Git that you want your patchfile in the feature-patches/ directory, and master..feature tells Git you want patches for the diff between master and feature - which in this case should be only one commit.

Now take a look in feature-patches/ . You should see a single file named something like 0001-component-my-great-feature.patch . If you open it up in your favorite editor (I like Vim), you’ll see an email header, your commit message, a diffspec, and a unified diff indicating your changes.

Ideally, your commit message should say everything there is to be said about your patch. But sometimes, there’s some context you want to add that isn’t appropriate for a commit message - for example, maybe you want to warn everyone that you won’t be addressing comments until next week as you’re visiting your aunt in Mallorca and she doesn’t like to give out her wifi password. In that case, look for the --- above the diffspec - you can provide your additional message there. It will look something like this:

Great. You can see in the example which parts of the email will be retained as a commit message, and which parts will be ignored by git am . If you’re not sure how it will look, you can always try running it through git am yourself to have a look at the resulting commit.

If your organization likes even single-commit changes to contain a cover letter you can just use the instructions in the next section.

Preparing a Patch Series with Cover Letter

If you’ve been working on a much larger feature and your branch has a number of commits, you can still use git format-patch pretty easily. Like before, make sure your working tree is clean and your commits are all in order, then run

Have a look in feature-patches/ . You should see n+1 patch files (where n is the number of commits you have on top of master). Most of them will reflect the subject lines of your patches, but there will be one named beginning with 0000 - that’s your cover letter. Go ahead and open it in your favorite editor.

You should see that it’s already got a template, including some email headers and a diffstat. Change the subject line to something that summarizes your entire feature, taking care to preserve the “[PATCH 0/X]” portion. You can also include context in the body of the cover letter to explain anything about the patchset which wasn’t appropriate for inclusion into the commit messages. For a larger changeset, this is typically the place where you explain what your feature is as a whole .

If you examine the other patches, you will see that they are all marked In-Reply-To the Message-Id of your cover letter. This is good and what most communities prefer, but you can change the behavior with the --thread argument.

Some Tips for Format-Patch

• Resist the urge to edit the diff in the patch directly. The diff contains some line number information that needs to match up and is hard to fudge by hand. Plus, your local tree will get out-of-sync with what you’re sending upstream.
• The timestamp at the top of the patch is special and indicates that the patch was generated with git format-patch ; don’t touch it.
• The build number at the bottom indicates which version of Git you used to generate the patch; you can delete this if you are feeling the need for privacy.
• The area below the --- or the cover letter in v2 or later patches is a great spot for you to explain what changed between the previous version and this one. Your reviewer could use an interdiff to figure it out, but it’s kind to give them a hint.

Show Them What You Got: git send-email

Note: One thing this tutorial won’t cover is how to download and configure git send-email . Not because it’s hard, or trivial, but because setup steps vary quite a bit depending on your system and email client. send-email is often not packaged with base Git; you may have to install it separately. This tutorial assumes you’ve already got it up and running.

After the steps in the previous section, you should have one or more patch files in your feature-patches/ directory, and you should also have examined your patches to ensure that they look perfect and ready for review. Sending them is as simple as this:

That’s it! Your patches are out and your reviews should come pouring in. (Okay, maybe “trickling” is a better word.)

Responding to Comments

Note: As with Gerrit and other iterative code review tools based around a Git workflow, making your changes involves using interactive rebase. I won’t cover that here, as it’s not significantly different from other processes, and it’s complex enough to take its own tutorial.

Your reviewers will likely provide their comments inline, and it’s often good manners to reply to each review comment indicating whether you’ve taken an action or not. When I’m replying to review comments, I like to have a window open with a reply to the email, and another window open with my code. I make sure that I’ve begun an interactive rebase and paused to edit the commit I’m examining comments for, and then I open my source file. As I read comments in the email, I make a change as appropriate in my source, then type a response inline to the comment in question. (That way I know I didn’t miss anything!)

When you’ve addressed all the comments for a certain patch, make sure to git add -u && git commit --amend to update your commit with the changes. Once you’ve updated your entire branch this way, you’re ready to send v2.

(You should include --cover-letter if you’re sending more than one patch. For a single patch, you should omit it.)

Take a look in feature-patches/ . You should see a new set of patches next to the old ones, this time preceding with v2- . Edit the cover letter or patch body to include details on the changes since v1.

As long as you’ve got In-Reply-To: set up correctly on your single patch or cover letter, you can send almost just like before; just make sure to target the v2 patches:

A Happy Emailed-Patch Developer

There you have it! Emailed patches aren’t so bad with the help of a couple handy Git tools. While they’re a little bit more effort than a push to Gerrit, I’d argue that the time spent editing the cover letter is about equitable to the time spent writing the message associated with the review in a graphical tool. Plus, the ability to perform reviews via email means you can get really wild and set up something like mutt so you can both review code and respond to reviews of your own code within your favorite editor - and is there anything that isn’t made more fun by the addition of Vim keybindings?

Happy hacking!

Using git with email: a Quick Tutorial

"wait what's all that about", preliminary settings, exporting with format-patch, sending with send-email, applying with am.

I am mostly writing this as a self memo for how to use git-send-email , and by extension git-format-patch and git-am , to share patches, patchsets, and apply them.

Me and my friends like to do these overly elaborate things to share code, what we jokingly call "fossbro roleplaying", so hopefully it can help them, and you as well!

These commands let you create patches that represent a commit (with all of its metadata, save for cryptographic signature), share them automatically over email, and, once someone downloads the contents of your email, apply those commits to a tree.

TL;DR: These are the settings you want to tweak. Mine would be:

These settings replace CLI parameters you can otherwise provide when sending email with git send-email .

The git-format-patch commands turns a commit or set of commits into files that can be straightforwardly sent as email.

The only real positional argument provides the range or set of commits to format. That can be quite hard to wrap your head around but here's a quick rundown:

Note that because git is the way it is, and because, when you think about it, it makes sense: when your range includes a divergence, you might pull all of the divergent commit from it. It's just how git works. In the end, you will get all the commits you need, but they will be linearized, so the application order might be a bit wonky or cause merge errors.

Everything else is just optional arguments. Here are those I think would be the most useful:

• --rfc : your patch or patchset is a request for comments
• -v <n> : mark this as version <n> of your patchset
• --cover-letter : generate a file that represents the cover letter, or the big description you send to explain the whole point of your patchset; by default it contains diff stats, and such
• --thread=<style> : the thread style controls how your commits follow each other. A shallow style means all subsequent email are a reply to the first one (typically the cover letter). That is the standard on LKLMs.
• --in-reply-to=<message-id> : oddly enough, I have already had to send a patch as a reply to a human-made series of email. This may be useful for that purpose.

This is the big complex part. Technically, git-send-email is a big Perl script that wraps around calls to your mail sender. As such, you may find some missing dependencies such as perl-authen-sasl on Arch Linux.

The send-email command takes your files and sends them as email. Easy. Except it does a lot of things for you and is very fuzzy in terms of available options. For example, it takes all emails from the Signed-off-by: and such lines in your commits, and adds them as Cc: lines in the email sent unless you tell it not to.

Here are the options I generally use:

• --to=<email> : a new To: line
• --cc= : a new Cc: line
• --bcc= : a new Bcc: line
• --compose : if you did not generate and edit a cover letter, write it now
• --no-signed-off-by-cc : this removes the automated gathering of emails in the Signed-off-by: lines to Cc:
• --suppress-cc=<choice> : suppress automatically found Cc: , you can see the man page for all choices
• --dry-run : do everything but send the actual email; the information sent to the SMTP server is shown in the standard output for debugging purposes

There is actually an interesting overlap between send-email and format-patch . You can actually configure most of everything you want for the content of your email messages via either command, depending on your choice. For example, had I not chosen threading style in format-patch , I could have specified it in send-email using --[no-]chain-reply-to .

If you find yourself the (un?)fortunate recipient of a patchset that you fancy adding to your project, you can simply download your email to files (or, honestly, just copy the visible content from your email browser), and run git am on them. Ideally, you want to apply them in order , and over the correct commit. The details for how to coordinate with your collaborators for that to happen is left at your own discretion.

Interestingly, you can use -S with am to sign the objects created. The signature from the original committer in their own repository cannot be maintained, because you create the actual binary git objects tied to that commit in the actual repository yourself, so you must sign and certify that the content you create that commit with is valid. You are the first person liable if something wrong is introduced (and others are on the line if there are Signed-off-by: lines).

As as interesting side note, many places will let you download .patch files that have the correct format to be an email and a git patch. For example:

• GitHub lets you do so for individual commits by adding .patch at the end of the URL, and similarly with pull requests (except the patch contains all individual patches for the PR's commits)
• GitLab does the exact same thing for both commits and merge requests
• Gitea/Forgejo also lets you do the same on both commits and PRs

As a result, you will often find yourself using git am on things that are not purely email.

As an addendum, I can point you to another tutorial by Matheus Tavares.

DESCRIPTION

Configuration.

Powered by the Ubuntu Manpage Repository , file bugs in Launchpad

# git send-email

# use git send-email with gmail.

Background: if you work on a project like the Linux kernel, rather than make a pull request you will need to submit your commits to a listserv for review. This entry details how to use git-send email with Gmail.

Add the following to your .gitconfig file:

Then on the web: Go to Google -> My Account -> Connected Apps & Sites -> Allow less secure apps -> Switch ON

To create a patch set:

Then send the patches to a listserv:

To create and send updated version (version 2 in this example) of the patch:

# Composing

--from * Email From: --[no-]to * Email To: --[no-]cc * Email Cc: --[no-]bcc * Email Bcc: --subject * Email "Subject:" --in-reply-to * Email "In-Reply-To:" --[no-]xmailer * Add "X-Mailer:" header (default). --[no-]annotate * Review each patch that will be sent in an editor. --compose * Open an editor for introduction. --compose-encoding * Encoding to assume for introduction. --8bit-encoding * Encoding to assume 8bit mails if undeclared --transfer-encoding * Transfer encoding to use (quoted-printable, 8bit, base64)

# Sending patches by mail

Suppose you’ve got a lot of commit against a project (here ulogd2, official branch is git-svn) and that you wan to send your patchset to the Mailling list [email protected]. To do so, just open a shell at the root of the git directory and use:

First command will create a serie of mail from patches in /tmp/ulogd2/ with statistic report and second will start your editor to compose an introduction mail to the patchset. To avoid awful threaded mail series, one can use :

(opens new window)

• git send-email [options] <file|directory|rev-list options>…​
• git send-email --dump-aliases

← Git statistics Git GUI Clients →

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

git send-email setup failure

I am unable to setup git send-mail to send a patch.

I following these two guides.

• git setup guide
• microsoft smtp config vishi@striker:~/$ cat ~/.gitconfig [user] name = vishalsinh email = [email protected] [core] autocrlf = false [sendemail] smtpencryption = STARTTLS smtpserver = smtp.office365.com smtpUser = [email protected] smtpServerPort = 587 confirm = auto

Used command this way.

I am getting bellow error.

Please give hints or docs that I can refer for solution.

Update: 31 jan 2023

Today I solved Domain name issue by specifically adding it by bellow command. after that there was encryption auth not known issue as git send-email does not have "STARTTLS" (git have TLS/SSL encryption). so set it to "tls"

now security defaults of microsoft AAD (Azure Active Directory) disables SMTP autentication. so I got bellow error.

with debug logs:

without debug logs:

now from 5.7.139 error and links provided provided + this similar error link I found that the only issue left is my default outlook server security defaults turn of "SMTP AUTH". admin needs to enable it but since I am not admin. I will stop here and use personal Gmail instead.

• Please try with the --smtp-debug flag enabled as indicated in the error message, and edit your question to include the result. –  tripleee Jan 23, 2023 at 7:54
• 1 tried --smtp-debug got invalid domain name error as you can see in my edited question. thanks. if I can solve it. will post results. –  Vishal Parmar Jan 23, 2023 at 14:52

2 Answers 2

after reaching SMTP-AUTH 5.7.139 error as shown in edited question. I stopped as I did not have admin privileges to enable it.

so I did alternative setup "git send-email" with gmail following this thre guide

• gmail setup, Check Gmail through other email platforms
• git send-email initial setup
• troubleshoot 2-factor authentication. gmail Sign in with App Passwords

Change smtpencryption = STARTTLS to smtpencryption = tls

• It would be a good idea to explain what is different about the 2 commands. –  David Apr 27, 2023 at 8:21
• David: when STARTTLS used it gives senders server request to endrypt data it can be TLS or SSL. while 'tls' is encryption protocol which tells senders mail server specifically use TLS protocol encryption. materoy: the guide I had initialy used had tls but that didn't worked. I got this far only after using STARTTLS. reposting initial guide link –  Vishal Parmar May 8, 2023 at 5:09

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged git smtp sendmail ..

• The Overflow Blog
• Climbing the GenAI decision tree sponsored post
• Diverting more backdoor disasters
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network
• AI-generated content is not permitted on Ask Ubuntu
• Let's organize some chat workshops

Hot Network Questions

• How can we infallibly know that the Catholic Church is infallible?
• How can I make this code more DRY
• Consequences of imposing conditions on the restricted Yoneda embedding of a functor
• What bike should I buy if I want to fit a child seat and live in area with a lot of hills?
• Can I mark a local variable as safe for a single file only?
• How do I measure well-being without Utility function?
• Why are the solar prominences visible during a total solar eclipse - orange? Is the sun orange?
• Why isn't there financial safety if I am arrested illegally?
• Difference between 当て and はず
• can a manager ask me to find someone to cover shifts AFTER I quit?
• Cheapest mandatory loop in Magic the Gathering
• Co-Existing with a Highly Extroverted Leader and "Forced Fun"
• In the Wallace and Gromit movies we see 'Electronics for Dogs.' Do we ever see any other 'books for Dogs' in-universe?
• What is SpaceX doing differently with their Falcon 9 so that it doesn't cost as much as the Space Shuttle?
• Does value of a TRS only involve past price movement and not expected returns?
• Segmentation of a network at branches from one complex boundary polygon
• Clearing certain lines in the Tabular environment
• Did Goethe say this quote praising the Prophet Muhammed?
• Factoring through projective modules is an equivalence relation
• To what extent can citizens of democracies be held responsible for the acts of their governments?
• Security implications of increasing sudo timeout in terminal
• Can falsehood be measured? If so, would it be continuous or discrete?
• What is a safe way to transport an e-bike battery on planes?
• Are agent explanations better than non agent explanations?

• Developer Information
• QEMU Community Processes
• Submitting a Patch
• Edit on GitLab

Submitting a Patch 

QEMU welcomes contributions to fix bugs, add functionality or improve the documentation. However, we get a lot of patches, and so we have some guidelines about submitting them. If you follow these, you’ll help make our task of contribution review easier and your change is likely to be accepted and committed faster.

This page seems very long, so if you are only trying to post a quick one-shot fix, the bare minimum we ask is that:

You do not have to subscribe to post (list policy is to reply-to-all to preserve CCs and keep non-subscribers in the loop on the threads they start), although you may find it easier as a subscriber to pick up good ideas from other posts. If you do subscribe, be prepared for a high volume of email, often over one thousand messages in a week. The list is moderated; first-time posts from an email address (whether or not you subscribed) may be subject to some delay while waiting for a moderator to allow your address.

The larger your contribution is, or if you plan on becoming a long-term contributor, then the more important the rest of this page becomes. Reading the table of contents below should already give you an idea of the basic requirements. Use the table of contents as a reference, and read the parts that you have doubts about.

Writing your Patches 

Use the qemu coding style .

You can run run scripts/checkpatch.pl <patchfile> before submitting to check that you are in compliance with our coding standards. Be aware that checkpatch.pl is not infallible, though, especially where C preprocessor macros are involved; use some common sense too. See also:

QEMU Coding Style

Automate a checkpatch run on commit

Base patches against current git master 

There’s no point submitting a patch which is based on a released version of QEMU because development will have moved on from then and it probably won’t even apply to master. We only apply selected bugfixes to release branches and then only as backports once the code has gone into master.

It is also okay to base patches on top of other on-going work that is not yet part of the git master branch. To aid continuous integration tools, such as patchew , you should add a tag line Based-on: $MESSAGE_ID to your cover letter to make the series dependency obvious.

Split up long patches 

Split up longer patches into a patch series of logical code changes. Each change should compile and execute successfully. For instance, don’t add a file to the makefile in patch one and then add the file itself in patch two. (This rule is here so that people can later use tools like git bisect without hitting points in the commit history where QEMU doesn’t work for reasons unrelated to the bug they’re chasing.) Put documentation first, not last, so that someone reading the series can do a clean-room evaluation of the documentation, then validate that the code matched the documentation. A commit message that mentions “Also, …” is often a good candidate for splitting into multiple patches. For more thoughts on properly splitting patches and writing good commit messages, see this advice from OpenStack .

Make code motion patches easy to review 

If a series requires large blocks of code motion, there are tricks for making the refactoring easier to review. Split up the series so that semantic changes (or even function renames) are done in a separate patch from the raw code motion. Use a one-time setup of git config diff.renames true; git config diff.algorithm patience (refer to git-config ). The ‘diff.renames’ property ensures file rename patches will be given in a more compact representation that focuses only on the differences across the file rename, instead of showing the entire old file as a deletion and the new file as an insertion. Meanwhile, the ‘diff.algorithm’ property ensures that extracting a non-contiguous subset of one file into a new file, but where all extracted parts occur in the same order both before and after the patch, will reduce churn in trying to treat unrelated } lines in the original file as separating hunks of changes.

Ideally, a code motion patch can be reviewed by doing:

to focus on the few changes that weren’t wholesale code motion.

Don’t include irrelevant changes 

In particular, don’t include formatting, coding style or whitespace changes to bits of code that would otherwise not be touched by the patch. (It’s OK to fix coding style issues in the immediate area (few lines) of the lines you’re changing.) If you think a section of code really does need a reindent or other large-scale style fix, submit this as a separate patch which makes no semantic changes; don’t put it in the same patch as your bug fix.

For smaller patches in less frequently changed areas of QEMU, consider using the Trivial Patches process.

Write a meaningful commit message 

Commit messages should be meaningful and should stand on their own as a historical record of why the changes you applied were necessary or useful.

QEMU follows the usual standard for git commit messages: the first line (which becomes the email subject line) is “subsystem: single line summary of change”. Whether the “single line summary of change” starts with a capital is a matter of taste, but we prefer that the summary does not end in a dot. Look at git shortlog -30 for an idea of sample subject lines. Then there is a blank line and a more detailed description of the patch, another blank and your Signed-off-by: line. Please do not use lines that are longer than 76 characters in your commit message (so that the text still shows up nicely with “git show” in a 80-columns terminal window).

The body of the commit message is a good place to document why your change is important. Don’t include comments like “This is a suggestion for fixing this bug” (they can go below the --- line in the email so they don’t go into the final commit message). Make sure the body of the commit message can be read in isolation even if the reader’s mailer displays the subject line some distance apart (that is, a body that starts with “… so that” as a continuation of the subject line is harder to follow).

If your patch fixes a commit that is already in the repository, please add an additional line with “Fixes: <at-least-12-digits-of-SHA-commit-id> (“Fixed commit subject”)” below the patch description / before your “Signed-off-by:” line in the commit message.

If your patch fixes a bug in the gitlab bug tracker, please add a line with “Resolves: <URL-of-the-bug>” to the commit message, too. Gitlab can close bugs automatically once commits with the “Resolved:” keyword get merged into the master branch of the project. And if your patch addresses a bug in another public bug tracker, you can also use a line with “Buglink: <URL-of-the-bug>” for reference here, too.

Some other tags that are used in commit messages include “Message-Id:” “Tested-by:”, “Acked-by:”, “Reported-by:”, “Suggested-by:”. See git log for these keywords for example usage.

Test your patches 

Although QEMU uses various CI services that attempt to test patches submitted to the list, it still saves everyone time if you have already tested that your patch compiles and works. Because QEMU is such a large project the default configuration won’t create a testing pipeline on GitLab when a branch is pushed. See the CI variable documentation for details on how to control the running of tests; but it is still wise to also check that your patches work with a full build before submitting a series, especially if your changes might have an unintended effect on other areas of the code you don’t normally experiment with. See Testing in QEMU for more details on what tests are available.

Also, it is a wise idea to include a testsuite addition as part of your patches - either to ensure that future changes won’t regress your new feature, or to add a test which exposes the bug that the rest of your series fixes. Keeping separate commits for the test and the fix allows reviewers to rebase the test to occur first to prove it catches the problem, then again to place it last in the series so that bisection doesn’t land on a known-broken state.

Submitting your Patches 

The QEMU project uses a public email based workflow for reviewing and merging patches. As a result all contributions to QEMU must be sent as patches to the qemu-devel mailing list . Patch contributions should not be posted on the bug tracker, posted on forums, or externally hosted and linked to. (We have other mailing lists too, but all patches must go to qemu-devel, possibly with a Cc: to another list.) git send-email ( step-by-step setup guide and hints and tips ) works best for delivering the patch without mangling it, but attachments can be used as a last resort on a first-time submission.

If you cannot send patch emails 

In rare cases it may not be possible to send properly formatted patch emails. You can use sourcehut to send your patches to the QEMU mailing list by following these steps:

Register or sign in to your account

Add your SSH public key in meta | keys .

Publish your git branch using git push git@git.sr.ht:~USERNAME/qemu HEAD

Send your patches to the QEMU mailing list using the web-based git-send-email UI at https://git.sr.ht/~USERNAME/qemu/send-email

This video shows the web-based git-send-email workflow. Documentation is available here .

CC the relevant maintainer 

Send patches both to the mailing list and CC the maintainer(s) of the files you are modifying. look in the MAINTAINERS file to find out who that is. Also try using scripts/get_maintainer.pl from the repository for learning the most common committers for the files you touched.

In fact, you can automate this, via a one-time setup of git config sendemail.cccmd 'scripts/get_maintainer.pl --nogit-fallback' (Refer to git-config .)

Do not send as an attachment 

Send patches inline so they are easy to reply to with review comments. Do not put patches in attachments.

Use git format-patch 

Use the right diff format. git format-patch will produce patch emails in the right format (check the documentation to find out how to drive it). You can then edit the cover letter before using git send-email to mail the files to the mailing list. (We recommend git send-email because mail clients often mangle patches by wrapping long lines or messing up whitespace. Some distributions do not include send-email in a default install of git; you may need to download additional packages, such as ‘git-email’ on Fedora-based systems.) Patch series need a cover letter, with shallow threading (all patches in the series are in-reply-to the cover letter, but not to each other); single unrelated patches do not need a cover letter (but if you do send a cover letter, use --numbered so the cover and the patch have distinct subject lines). Patches are easier to find if they start a new top-level thread, rather than being buried in-reply-to another existing thread.

Avoid posting large binary blob 

If you added binaries to the repository, consider producing the patch emails using git format-patch --no-binary and include a link to a git repository to fetch the original commit.

Patch emails must include a Signed-off-by: line 

Your patches must include a Signed-off-by: line. This is a hard requirement because it’s how you say “I’m legally okay to contribute this and happy for it to go into QEMU”. The process is modelled after the Linux kernel policy.

If you wrote the patch, make sure your “From:” and “Signed-off-by:” lines use the same spelling. It’s okay if you subscribe or contribute to the list via more than one address, but using multiple addresses in one commit just confuses things. If someone else wrote the patch, git will include a “From:” line in the body of the email (different from your envelope From:) that will give credit to the correct author; but again, that author’s Signed-off-by: line is mandatory, with the same spelling.

There are various tooling options for automatically adding these tags include using git commit -s or git format-patch -s . For more information see SubmittingPatches 1.12 .

Include a meaningful cover letter 

This is a requirement for any series with multiple patches (as it aids continuous integration), but optional for an isolated patch. The cover letter explains the overall goal of such a series, and also provides a convenient 0/N email for others to reply to the series as a whole. A one-time setup of git config format.coverletter auto (refer to git-config ) will generate the cover letter as needed.

When reviewers don’t know your goal at the start of their review, they may object to early changes that don’t make sense until the end of the series, because they do not have enough context yet at that point of their review. A series where the goal is unclear also risks a higher number of review-fix cycles because the reviewers haven’t bought into the idea yet. If the cover letter can explain these points to the reviewer, the process will be smoother patches will get merged faster. Make sure your cover letter includes a diffstat of changes made over the entire series; potential reviewers know what files they are interested in, and they need an easy way determine if your series touches them.

Use the RFC tag if needed 

For example, “[PATCH RFC v2]”. git format-patch --subject-prefix=RFC can help.

“RFC” means “Request For Comments” and is a statement that you don’t intend for your patchset to be applied to master, but would like some review on it anyway. Reasons for doing this include:

the patch depends on some pending kernel changes which haven’t yet been accepted, so the QEMU patch series is blocked until that dependency has been dealt with, but is worth reviewing anyway

the patch set is not finished yet (perhaps it doesn’t cover all use cases or work with all targets) but you want early review of a major API change or design structure before continuing

In general, since it’s asking other people to do review work on a patchset that the submitter themselves is saying shouldn’t be applied, it’s best to:

use it sparingly

in the cover letter, be clear about why a patch is an RFC, what areas of the patchset you’re looking for review on, and why reviewers should care

Consider whether your patch is applicable for stable 

If your patch fixes a severe issue or a regression, it may be applicable for stable. In that case, consider adding Cc: qemu-stable@nongnu.org to your patch to notify the stable maintainers.

For more details on how QEMU’s stable process works, refer to the QEMU and the stable process page.

Participating in Code Review 

All patches submitted to the QEMU project go through a code review process before they are accepted. This will often mean a series will go through a number of iterations before being picked up by maintainers . You therefore should be prepared to read replies to your messages and be willing to act on them.

Maintainers are often willing to manually fix up first-time contributions, since there is a learning curve involved in making an ideal patch submission. However for the best results you should proactively respond to suggestions with changes or justifications for your current approach.

Some areas of code that are well maintained may review patches quickly, lesser-loved areas of code may have a longer delay.

Stay around to fix problems raised in code review 

Not many patches get into QEMU straight away – it is quite common that developers will identify bugs, or suggest a cleaner approach, or even just point out code style issues or commit message typos. You’ll need to respond to these, and then send a second version of your patches with the issues fixed. This takes a little time and effort on your part, but if you don’t do it then your changes will never get into QEMU.

Remember that a maintainer is under no obligation to take your patches. If someone has spent the time reviewing your code and suggesting improvements and you simply re-post without either addressing the comment directly or providing additional justification for the change then it becomes wasted effort. You cannot demand others merge and then fix up your code after the fact.

When replying to comments on your patches reply to all and not just the sender – keeping discussion on the mailing list means everybody can follow it. Remember the spirit of the Code of Conduct and keep discussions respectful and collaborative and avoid making personal comments.

Pay attention to review comments 

Someone took their time to review your work, and it pays to respect that effort; repeatedly submitting a series without addressing all comments from the previous round tends to alienate reviewers and stall your patch. Reviewers aren’t always perfect, so it is okay if you want to argue that your code was correct in the first place instead of blindly doing everything the reviewer asked. On the other hand, if someone pointed out a potential issue during review, then even if your code turns out to be correct, it’s probably a sign that you should improve your commit message and/or comments in the code explaining why the code is correct.

If you fix issues that are raised during review resend the entire patch series not just the one patch that was changed. This allows maintainers to easily apply the fixed series without having to manually identify which patches are relevant. Send the new version as a complete fresh email or series of emails – don’t try to make it a followup to version 1. (This helps automatic patch email handling tools distinguish between v1 and v2 emails.)

When resending patches add a version tag 

All patches beyond the first version should include a version tag – for example, “[PATCH v2]”. This means people can easily identify whether they’re looking at the most recent version. (The first version of a patch need not say “v1”, just [PATCH] is sufficient.) For patch series, the version applies to the whole series – even if you only change one patch, you resend the entire series and mark it as “v2”. Don’t try to track versions of different patches in the series separately. git format-patch and git send-email both understand the -v2 option to make this easier. Send each new revision as a new top-level thread, rather than burying it in-reply-to an earlier revision, as many reviewers are not looking inside deep threads for new patches.

Include version history in patchset revisions 

For later versions of patches, include a summary of changes from previous versions, but not in the commit message itself. In an email formatted as a git patch, the commit message is the part above the --- line, and this will go into the git changelog when the patch is committed. This part should be a self-contained description of what this version of the patch does, written to make sense to anybody who comes back to look at this commit in git in six months’ time. The part below the --- line and above the patch proper (git format-patch puts the diffstat here) is a good place to put remarks for people reading the patch email, and this is where the “changes since previous version” summary belongs. The git-publish script can help with tracking a good summary across versions. Also, the git-backport-diff script can help focus reviewers on what changed between revisions.

Tips and Tricks 

Proper use of reviewed-by: tags can aid review .

When reviewing a large series, a reviewer can reply to some of the patches with a Reviewed-by tag, stating that they are happy with that patch in isolation (sometimes conditional on minor cleanup, like fixing whitespace, that doesn’t affect code content). You should then update those commit messages by hand to include the Reviewed-by tag, so that in the next revision, reviewers can spot which patches were already clean from the previous round. Conversely, if you significantly modify a patch that was previously reviewed, remove the reviewed-by tag out of the commit message, as well as listing the changes from the previous version, to make it easier to focus a reviewer’s attention to your changes.

If your patch seems to have been ignored 

If your patchset has received no replies you should “ping” it after a week or two, by sending an email as a reply-to-all to the patch mail, including the word “ping” and ideally also a link to the page for the patch on patchew or lore.kernel.org . It’s worth double-checking for reasons why your patch might have been ignored (forgot to CC the maintainer? annoyed people by failing to respond to review comments on an earlier version?), but often for less-maintained areas of QEMU patches do just slip through the cracks. If your ping is also ignored, ping again after another week or so. As the submitter, you are the person with the most motivation to get your patch applied, so you have to be persistent.

Is my patch in? 

QEMU has some Continuous Integration machines that try to catch patch submission problems as soon as possible. patchew includes a web interface for tracking the status of various threads that have been posted to the list, and may send you an automated mail if it detected a problem with your patch.

Once your patch has had enough review on list, the maintainer for that area of code will send notification to the list that they are including your patch in a particular staging branch. Periodically, the maintainer then takes care of Submitting a Pull Request for aggregating topic branches into mainline QEMU. Generally, you do not need to send a pull request unless you have contributed enough patches to become a maintainer over a particular section of code. Maintainers may further modify your commit, by resolving simple merge conflicts or fixing minor typos pointed out during review, but will always add a Signed-off-by line in addition to yours, indicating that it went through their tree. Occasionally, the maintainer’s pull request may hit more difficult merge conflicts, where you may be requested to help rebase and resolve the problems. It may take a couple of weeks between when your patch first had a positive review to when it finally lands in qemu.git; release cycle freezes may extend that time even longer.

Return the favor 

Peer review only works if everyone chips in a bit of review time. If everyone submitted more patches than they reviewed, we would have a patch backlog. A good goal is to try to review at least as many patches from others as what you submit. Don’t worry if you don’t know the code base as well as a maintainer; it’s perfectly fine to admit when your review is weak because you are unfamiliar with the code.

• Português (Brasil)

Setup and Config

Getting and creating projects, basic snapshotting, branching and merging, sharing and updating projects, inspection and comparison.

• cherry-pick
• format-patch
• request-pull

External Systems

• fast-import

Server Admin

• update-server-info
• gitattributes
• Command-line interface conventions
• Everyday Git
• Frequently Asked Questions (FAQ)
• All guides...

Administration

• filter-branch

Plumbing Commands

• check-ignore
• checkout-index
• commit-tree
• count-objects
• for-each-ref
• hash-object
• symbolic-ref
• update-index
• verify-pack
• 2.43.2 → 2.44.0 no changes

• 2.38.1 → 2.42.1 no changes
• 2.29.1 → 2.37.7 no changes
• See more previous releases →

git-imap-send - Send a collection of patches from stdin to an IMAP folder

DESCRIPTION

This command uploads a mailbox generated with git format-patch into an IMAP drafts folder. This allows patches to be sent as other email is when using mail clients that cannot read mailbox files directly. The command also works with any general mailbox in which emails have the fields "From", "Date", and "Subject" in that order.

Typical usage is something like:

git format-patch --signoff --stdout --attach origin | git imap-send

Be verbose.

Use libcurl to communicate with the IMAP server, unless tunneling into it. Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND option set.

Talk to the IMAP server using git’s own IMAP routines instead of using libcurl. Ignored if Git was built with the NO_OPENSSL option set.

CONFIGURATION

To use the tool, imap.folder and either imap.tunnel or imap.host must be set to appropriate values.

Everything above this line in this section isn’t included from the git-config[1] documentation. The content that follows is the same as what’s found there:

The folder to drop the mails into, which is typically the Drafts folder. For example: "INBOX.Drafts", "INBOX/Drafts" or "[Gmail]/Drafts". Required.

Command used to set up a tunnel to the IMAP server through which commands will be piped instead of using a direct network connection to the server. Required when imap.host is not set.

A URL identifying the server. Use an imap:// prefix for non-secure connections and an imaps:// prefix for secure connections. Ignored when imap.tunnel is set, but required otherwise.

The username to use when logging in to the server.

The password to use when logging in to the server.

An integer port number to connect to on the server. Defaults to 143 for imap:// hosts and 993 for imaps:// hosts. Ignored when imap.tunnel is set.

A boolean to enable/disable verification of the server certificate used by the SSL/TLS connection. Default is true . Ignored when imap.tunnel is set.

A boolean to enable/disable the use of html encoding when sending a patch. An html encoded patch will be bracketed with <pre> and have a content type of text/html. Ironically, enabling this option causes Thunderbird to send the patch as a plain/text, format=fixed email. Default is false .

Specify the authentication method for authenticating with the IMAP server. If Git was built with the NO_CURL option, or if your curl version is older than 7.34.0, or if you’re running git-imap-send with the --no-curl option, the only supported method is CRAM-MD5 . If this is not set then git imap-send uses the basic IMAP plaintext LOGIN command.

Using tunnel mode:

Using direct mode:

Using direct mode with SSL:

Using Gmail’s IMAP interface:

Once the commits are ready to be sent, run the following command:

Just make sure to disable line wrapping in the email client (Gmail’s web interface will wrap lines no matter what, so you need to use a real IMAP client).

It is still your responsibility to make sure that the email message sent by your email program meets the standards of your project. Many projects do not like patches to be attached. Some mail agents will transform patches (e.g. wrap lines, send them as format=flowed) in ways that make them fail. You will get angry flames ridiculing you if you don’t check this.

Thunderbird in particular is known to be problematic. Thunderbird users may wish to visit this web page for more information: https://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email

git-format-patch[1] , git-send-email[1] , mbox(5)

Part of the git[1] suite

[PATCH] send-email: Refuse to send cover-letter template subject

• Subject : [PATCH] send-email: Refuse to send cover-letter template subject
• From : Thomas Rast < trast@xxxxxxxxxxxxxxx >
• Date : Mon, 8 Jun 2009 23:34:12 +0200
• Cc : Junio C Hamano < gitster@xxxxxxxxx >
• From: Junio C Hamano
• Prev by Date: Re: [PATCH] autoconf: Add link tests to each AC_CHECK_FUNC() test
• Next by Date: Re: [PATCH 1/2] Documentation: mention 'git stash pop --index' option explicitly
• Previous by thread: Re: [PATCH] autoconf: Add link tests to each AC_CHECK_FUNC() test
• Next by thread: Re: [PATCH] send-email: Refuse to send cover-letter template subject