Add send-email notes to Git/notes.org.

diff --git a/posts/Git/notes.org b/posts/Git/notes.org
index 5c6da8c42dd07e83c9ad0803a21ba12f689878d3..d9dd58922b6c8ca34427f99c58099bfa15786034 100644 (file)
--- a/posts/Git/notes.org
+++ b/posts/Git/notes.org
@@ -848,6 +848,73 @@ convenient for tracking down kernel bugs.  You need to run =git bisect
 reset= to clear that state.  If you're nervous, you can save the state
 on your own with =git bisect log > your-file=.
 
+** Automatic CCs with =git send-email=
+
+The Linux kernel and Git mailing list (and other projects) prefer
+patch submissions via email (vs. pull requests), so that everyone can
+make line-by-line comments on the submissions before the patches are
+committed to the main development repositories.  The Git commands that
+facilitate this technique are =format-patch=, =send-email=, and =am=.
+Here's how things will usually work.  We'll start off following the
+patch developer.  It saves typing in the long run if you configure
+some defaults first:
+
+    : $ git config --global user.name "John Doe"
+    : $ git config --global user.email jdoe@invalid.com
+    : $ git config --global user.signingkey 0x0123456789ABCDEF
+    : $ git config --global format.thread true
+    : $ git config --global sendemail.cc-cmd ~/bin/git-cc
+    : $ git config --global sendemail.aliasesfile ~/.mutt/aliases
+    : $ git config --global sendemail.aliasfiletype mutt
+    : $ echo 'alias git-list git@vger.kernel.org' >> ~/.mutt/aliases
+
+The =git-cc= command is a slick, =git-blame=\-based script by [[http://felipec.wordpress.com/2009/10/25/git-send-email-tricks/][Felipe
+Contreras]] ([[http://gist.github.com/218093][gist]]).
+
+Checkout the source, and start your development branch:
+
+    : $ git clone git://github.com/gitster/git.git
+    : $ cd git
+    : $ git config sendemail.to git-list
+    : $ git checkout -b dev/my-feature
+
+Make your changes:
+
+    : $ emacs gitweb/gitweb.perl
+    :   (hack, hack, hack, …)
+    : $ git commit -am "gitweb: refactor …"
+
+If upstream has moved on, rebase your changes onto the new trunk:
+
+    : $ git checkout master
+    : $ git pull
+    : $ git rebase master dev/my-feature
+
+and mail them upstream:
+
+    : $ git send-email --signoff --annotate --cover-letter origin/master
+
+You can record your patches for comparison with:
+
+    : $ git format-patch --output-directory patch-my-feature-v1 origin/master
+
+When you hear back with comments on how to improve the patch set, make
+the appropriate changes with:
+
+    : $ git checkout dev/my-feature
+    : $ git rebase -i
+    : $ git checkout master
+    : $ git pull
+    : $ git rebase master dev/my-feature
+
+Then send off an updated version:
+
+    : $ git format-patch --output-directory patch-my-feature-v2
+    : $ git diff -ru patch-my-feature-v{1,2} > /tmp/diff-for-cover-letter
+    : $ git send-email --signoff --annotate --cover-letter --subject-prefix 'PATCH v2' origin/master
+
+See =gitworkflows(7)= for other good ideas.
+
 * Troubleshooting
 ** Git commit hangs with no output