{"thread":{"id":"27088","subject":"[PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","startedAt":"2011-04-13T15:39:40Z","lastAt":"2011-04-18T06:31:16Z","messageCount":26,"participants":["Jim Meyering","Drew Northup","Junio C Hamano","Jonathan Nieder","Jakub Narebski","Johannes Sixt","Michael J Gruber","Michele Ballabio"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"165755","messageId":"87d3kq6tz7.fsf@rho.meyering.net","threadId":"27088","inReplyTo":null,"subject":"[PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2011-04-13T15:39:40Z","receivedAt":"2011-04-13T15:39:40Z","isPatch":true,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"I found that some doubled words had snuck back into projects from\nwhich I'd already removed them, so now there's a \"syntax-check\" makefile\nrule in gnulib to help prevent recurrence. Running the command below\nspotted a few in git, too:\n\nThis patch is relative to \"next\".\n\n>From d21d6f61bbeeba4a754cdcded66ca86a709695ee Mon Sep 17 00:00:00 2001\nFrom: Jim Meyering \nDate: Wed, 13 Apr 2011 17:34:44 +0200\nSubject: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related\n typos\n\nRun this command to identify suspects:\ngit ls-files | xargs perl -0777 -n \\\n -e 'while (/\\b(then?|[iao]n|i[fst]|but|f?or|at|and|[dt])\\s+\\1\\b/gims)' \\\n -e '{$n=($` =~ tr/\\n/\\n/ + 1); ($v=$&)=~s/\\n/\\\\n/g;' \\\n -e 'print \"$ARGV:$n:$v\\n\"}'\n* Documentation/SubmittingPatches: Remove doubled \"to\".\n* Documentation/git-fetch.txt: Remove doubled \"or\".\n* Documentation/git-pack-objects.txt: Remove doubled \"it\".\n* compat/mingw.c: Likewise.\n* compat/nedmalloc/malloc.c.h: Change \"an an\" to \"as an\".\nRemove doubled \"is\" and \"or\".\n* gitweb/README: Change \"Is is\" to \"This is\".\n* sha1_file.c: Remove doubled \"at\" in comment.\n* vcs-svn/trp.txt: Remove doubled \"if\".\n\nSigned-off-by: Jim Meyering \n---\n Documentation/SubmittingPatches | 3 +--\n Documentation/git-fetch.txt | 2 +-\n Documentation/git-pack-objects.txt | 2 +-\n compat/mingw.c | 2 +-\n compat/nedmalloc/malloc.c.h | 10 ++++------\n gitweb/README | 2 +-\n sha1_file.c | 2 +-\n vcs-svn/trp.txt | 2 +-\n 8 files changed, 11 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex c3b0816..c6a5032 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -276,7 +276,7 @@ don't hide your real name.\n\n If you like, you can put extra tags at the end:\n\n-1. \"Reported-by:\" is used to to credit someone who found the bug that\n+1. \"Reported-by:\" is used to credit someone who found the bug that\n the patch attempts to fix.\n 2. \"Acked-by:\" says that the person who is more familiar with the area\n the patch attempts to modify liked the patch.\n@@ -608,4 +608,3 @@ following commands:\n Just make sure to disable line wrapping in the email client (GMail web\n interface will line wrap no matter what, so you need to use a real\n IMAP client).\n-\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex 67d2214..60ac8d2 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -34,7 +34,7 @@ pointed by remote tags that it does not yet have, then fetch\n those missing tags. If the other end has tags that point at\n branches you are not interested in, you will not get them.\n\n-'git fetch' can fetch from either a single named repository, or\n+'git fetch' can fetch from either a single named repository,\n or from several repositories at once if is given and\n there is a remotes. entry in the configuration file.\n (See linkgit:git-config[1]).\ndiff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt\nindex 08c89d2..20c8551 100644\n--- a/Documentation/git-pack-objects.txt\n+++ b/Documentation/git-pack-objects.txt\n@@ -115,7 +115,7 @@ base-name::\n\n --honor-pack-keep::\n \tThis flag causes an object already in a local pack that\n-\thas a .keep file to be ignored, even if it it would have\n+\thas a .keep file to be ignored, even if it would have\n \totherwise been packed.\n\n --incremental::\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 878b1de..4423961 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -1130,7 +1130,7 @@ char **make_augmented_environ(const char *const *vars)\n\n /*\n * Note, this isn't a complete replacement for getaddrinfo. It assumes\n- * that service contains a numerical port, or that it it is null. It\n+ * that service contains a numerical port, or that it is null. It\n * does a simple search using gethostbyname, and returns one IPv4 host\n * if one was found.\n */\ndiff --git a/compat/nedmalloc/malloc.c.h b/compat/nedmalloc/malloc.c.h\nindex 87260d2..ff7c2c4 100644\n--- a/compat/nedmalloc/malloc.c.h\n+++ b/compat/nedmalloc/malloc.c.h\n@@ -100,7 +100,7 @@\n\n If you don't like either of these options, you can define\n CORRUPTION_ERROR_ACTION and USAGE_ERROR_ACTION to do anything\n- else. And if if you are sure that your program using malloc has\n+ else. And if you are sure that your program using malloc has\n no errors or vulnerabilities, you can define INSECURE to 1,\n which might (or might not) provide a small performance improvement.\n\n@@ -2279,12 +2279,12 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n of the same size are arranged in a circularly-linked list, with only\n the oldest chunk (the next to be used, in our FIFO ordering)\n actually in the tree. (Tree members are distinguished by a non-null\n- parent pointer.) If a chunk with the same size an an existing node\n+ parent pointer.) If a chunk with the same size as an existing node\n is inserted, it is linked off the existing node using pointers that\n work in the same way as fd/bk pointers of small chunks.\n\n Each tree contains a power of 2 sized range of chunk sizes (the\n- smallest is 0x100 <= x < 0x180), which is is divided in half at each\n+ smallest is 0x100 <= x < 0x180), which is divided in half at each\n tree level, with the chunks in the smaller half of the range (0x100\n <= x < 0x140 for the top nose) in the left subtree and the larger\n half (0x140 <= x < 0x180) in the right subtree. This is, of course,\n@@ -3943,7 +3943,7 @@ static void* sys_alloc(mstate m, size_t nb) {\n least-preferred order):\n 1. A call to MORECORE that can normally contiguously extend memory.\n (disabled if not MORECORE_CONTIGUOUS or not HAVE_MORECORE or\n- or main space is mmapped or a previous contiguous call failed)\n+ main space is mmapped or a previous contiguous call failed)\n 2. A call to MMAP new space (disabled if not HAVE_MMAP).\n Note that under the default settings, if MORECORE is unable to\n fulfill a request, and HAVE_MMAP is true, then mmap is\n@@ -5748,5 +5748,3 @@ History:\n \t structure of old version, but most details differ.)\n\n */\n-\n-\ndiff --git a/gitweb/README b/gitweb/README\nindex 4a67393..a92bde7 100644\n--- a/gitweb/README\n+++ b/gitweb/README\n@@ -29,7 +29,7 @@ You can specify the following configuration variables when building GIT:\n The filesystem traversing limit for getting the project list; the number\n is taken as depth relative to the projectroot. It is used when\n GITWEB_LIST is a directory (or is not set; then project root is used).\n- Is is meant to speed up project listing on large work trees by limiting\n+ This is meant to speed up project listing on large work trees by limiting\n search depth. [Default: 2007]\n * GITWEB_LIST\n Points to a directory to scan for projects (defaults to project root\ndiff --git a/sha1_file.c b/sha1_file.c\nindex df0edba..889fe71 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1534,7 +1534,7 @@ static int unpack_object_header(struct packed_git *p,\n \tenum object_type type;\n\n \t/* use_pack() assures us we have [base, base + 20) available\n-\t * as a range that we can look at at. (Its actually the hash\n+\t * as a range that we can look at. (Its actually the hash\n \t * size that is assured.) With our object header encoding\n \t * the maximum deflated object size is 2^137, which is just\n \t * insane, so we know won't exceed what we have been given.\ndiff --git a/vcs-svn/trp.txt b/vcs-svn/trp.txt\nindex 5ca6b42..177ebca 100644\n--- a/vcs-svn/trp.txt\n+++ b/vcs-svn/trp.txt\n@@ -96,7 +96,7 @@ node_type *foo_search(struct trp_root \\*treap, node_type \\*key)::\n\n node_type *foo_nsearch(struct trp_root \\*treap, node_type \\*key)::\n\n-\tLike `foo_search`, but if if the key is missing return what\n+\tLike `foo_search`, but if the key is missing return what\n \twould be key's successor, were key in treap (NULL if no\n \tsuccessor).\n\n--\n1.7.5.rc1.228.g86d60b\n"},{"id":"165762","messageId":"1302719749.21047.6.camel@drew-northup.unet.maine.edu","threadId":"27088","inReplyTo":"87d3kq6tz7.fsf@rho.meyering.net","subject":"Re: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-04-13T18:35:49Z","receivedAt":"2011-04-13T18:35:49Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2011-04-13 at 17:39 +0200, Jim Meyering wrote:\n> I found that some doubled words had snuck back into projects from\n> which I'd already removed them, so now there's a \"syntax-check\" makefile\n> rule in gnulib to help prevent recurrence. Running the command below\n> spotted a few in git, too:\n> \n> This patch is relative to \"next\".\n\nJim,\nTry putting the output of git format-patch into your drafts folder, then\nopen that draft in your mail client. The output of format-patch isn't\nmeant to be pasted directly into a mail message.\n\n> \n> >From d21d6f61bbeeba4a754cdcded66ca86a709695ee Mon Sep 17 00:00:00 2001\n> From: Jim Meyering \n\n\n\nThe above tells me that you just dumped the output of format-patch into\nyour mail client. There is a full tutorial in\nDocumentation/SubmittingPatches in git.git.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"165763","messageId":"7vd3kqm1ib.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"87d3kq6tz7.fsf@rho.meyering.net","subject":"Re: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-13T18:47:56Z","receivedAt":"2011-04-13T18:47:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jim Meyering writes:\n\n> I found that some doubled words had snuck back into projects from\n> which I'd already removed them, so now there's a \"syntax-check\" makefile\n> rule in gnulib to help prevent recurrence.\n\nThanks.\n"},{"id":"165782","messageId":"87mxjtn8x7.fsf@rho.meyering.net","threadId":"27088","inReplyTo":"1302719749.21047.6.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2011-04-13T21:22:28Z","receivedAt":"2011-04-13T21:22:28Z","isPatch":true,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Drew Northup wrote:\n> On Wed, 2011-04-13 at 17:39 +0200, Jim Meyering wrote:\n>> I found that some doubled words had snuck back into projects from\n>> which I'd already removed them, so now there's a \"syntax-check\" makefile\n>> rule in gnulib to help prevent recurrence. Running the command below\n>> spotted a few in git, too:\n>>\n>> This patch is relative to \"next\".\n>\n> Jim,\n> Try putting the output of git format-patch into your drafts folder, then\n> open that draft in your mail client. The output of format-patch isn't\n> meant to be pasted directly into a mail message.\n\nI hope I haven't caused Junio or anyone else undue trouble.\nI know well how format-patch output can be used, but in the vast\nmajority of patch-including messages I send, I include format-patch\noutput mainly as an FYI, *following* commentary that does not\nbelong in the log, so it's ok there -- desirable, even.\n\nI find it slightly backwards to have to put non-log (i.e, intro\ncommentary) *after* the real log, and that's why I've developed\nthis habit.\n\nI'll try to remember to do it the other way when the\nrecipient is more likely to apply the patch.\n"},{"id":"165784","messageId":"20110413221736.GA773@elie","threadId":"27088","inReplyTo":"87mxjtn8x7.fsf@rho.meyering.net","subject":"[PATCH/RFC] Documentation/format-patch: summarize patch-sending workflow","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-13T22:17:36Z","receivedAt":"2011-04-13T22:17:36Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Jim,\n\nJim Meyering wrote:\n\n> I hope I haven't caused Junio or anyone else undue trouble.\n> I know well how format-patch output can be used, but in the vast\n> majority of patch-including messages I send, I include format-patch\n> output mainly as an FYI, *following* commentary that does not\n> belong in the log, so it's ok there -- desirable, even.\n\nSure, that's true. The main problem with including a patch in mbox\nformat inline is that the \"From \" line tends to get corrupted. How\nabout something like patch?\n\n-- 8< --\nSubject: Documentation/format-patch: summarize patch-sending workflow\n\nAdd a DISCUSSION section to encourage people to send patches in a\nform that can be applied by \"git am\" automatically. There are two\nsuch forms:\n\n 1. The default form in which most metadata goes in the mail header\n and the message body starts with the patch description;\n\n 2. The snipsnip form in which a message starts with pertinent\n discussion and ends with a patch after a \"scissors\" mark.\n\nWhile at it, include a pointer to Documentation/SubmittingPatches\nfor MUA-specific hints.\n\nInspired-by: Jim Meyering \nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-format-patch.txt | 48 +++++++++++++++++++++++++++++++++++-\n 1 files changed, 47 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex a5525e9..5118fdb 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -274,9 +274,55 @@ as e-mailable patches:\n $ git format-patch -3\n ------------\n \n+DISCUSSION\n+----------\n+The patch produced by 'git format-patch' is in UNIX mailbox format,\n+like so:\n+\n+------------\n+From f97e66080296c741200eacf1eaeb73f05b19e140 Mon Sep 17 00:00:00 2001\n+From: =?UTF-8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?= \n+Date: Sun, 10 Apr 2011 19:37:01 +0000\n+Subject: [PATCH] Makefile: extract Q_() source strings as ngettext()\n+MIME-Version: 1.0\n+Content-Type: text/plain; charset=UTF-8\n+Content-Transfer-Encoding: 8bit\n+\n+The patch adding the Q_() wrapper function around ngettext[1] didn't\n+contain a corresponding update to the \"pot\" target in the Makefile. As\n+...\n+------------\n+\n+Typically it will be placed in a MUA's drafts folder, edited to add\n+timely commentary that should not go in the changelog after the three\n+dashes, and then sent as a message whose body starts with \"The patch\n+adding the Q_() wrapper function ...\". On the receiving end, readers\n+can save interesting patches in a UNIX mailbox and apply them with\n+linkgit:git-am[1].\n+\n+'git am --scissors' accepts an alternative format with the patch\n+inline in the message:\n+\n+------------\n+...\n+> So we should do such-and-such.\n+\n+Makes sense to me. How about this patch?\n+\n+-- 8< --\n+From: Ævar Arnfjörð Bjarmason \n+Subject: Makefile: extract Q_() source strings as ngettext()\n+\n+The patch adding the Q_() wrapper function around ngettext[1] didn't\n+....\n+------------\n+\n+See linkgit:git-am[1] for details.\n+\n SEE ALSO\n --------\n-linkgit:git-am[1], linkgit:git-send-email[1]\n+linkgit:git-am[1], linkgit:git-send-email[1], linkgit:git-imap-send[1],\n+Documentation/SubmittingPatches\n \n GIT\n ---\n-- \n1.7.5.rc0\n"},{"id":"165786","messageId":"m3aaft3i2d.fsf@localhost.localdomain","threadId":"27088","inReplyTo":"87mxjtn8x7.fsf@rho.meyering.net","subject":"Re: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related typos","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-04-13T22:26:06Z","receivedAt":"2011-04-13T22:26:06Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jim Meyering writes:\n> Drew Northup wrote:\n>> On Wed, 2011-04-13 at 17:39 +0200, Jim Meyering wrote:\n\n>>> I found that some doubled words had snuck back into projects from\n>>> which I'd already removed them, so now there's a \"syntax-check\" makefile\n>>> rule in gnulib to help prevent recurrence. Running the command below\n>>> spotted a few in git, too:\n>>>\n>>> This patch is relative to \"next\".\n>>\n>> Jim,\n>> Try putting the output of git format-patch into your drafts folder, then\n>> open that draft in your mail client. The output of format-patch isn't\n>> meant to be pasted directly into a mail message.\n> \n> I hope I haven't caused Junio or anyone else undue trouble.\n> I know well how format-patch output can be used, but in the vast\n> majority of patch-including messages I send, I include format-patch\n> output mainly as an FYI, *following* commentary that does not\n> belong in the log, so it's ok there -- desirable, even.\n> \n> I find it slightly backwards to have to put non-log (i.e, intro\n> commentary) *after* the real log, and that's why I've developed\n> this habit.\n> \n> I'll try to remember to do it the other way when the\n> recipient is more likely to apply the patch.\n\nYou can put patch _after_ commentary, but if you do it this way you\nshould include \"scissors\" line to make it possible to extract commit\npart automatically by \"git am --scissors\", and remove unnecessary\nheaders.\n\nIn other words you had:\n\n> From d21d6f61bbeeba4a754cdcded66ca86a709695ee Mon Sep 17 00:00:00 2001\n> From: Jim Meyering \n> Date: Wed, 13 Apr 2011 17:34:44 +0200\n> Subject: [PATCH] remove doubled words, e.g., s/to to/to/, and fix related\n> typos\n> \n> Run this command to identify suspects:\n\nand you should have\n\n -- >8 --\n Run this command to identify suspects:\n\nor in case author is different from email from\n\n -- >8 --\n From: Jim Meyering \n\n Run this command to identify suspects:\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"165787","messageId":"7vzkntkc9d.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"20110413221736.GA773@elie","subject":"Re: [PATCH/RFC] Documentation/format-patch: summarize patch-sending workflow","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-13T22:38:38Z","receivedAt":"2011-04-13T22:38:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> + ...\n> +'git am --scissors' accepts an alternative format with the patch\n> +inline in the message:\n> +\n> +------------\n> +...\n> +> So we should do such-and-such.\n> +\n> +Makes sense to me. How about this patch?\n> +\n> +-- 8< --\n> +From: Ævar Arnfjörð Bjarmason \n> +Subject: Makefile: extract Q_() source strings as ngettext()\n> +\n> +The patch adding the Q_() wrapper function around ngettext[1] didn't\n> +....\n> +------------\n\nIt still is preferred to remove the magic \"From xxxx Mon Sep 17 00:00:00\n2001\" we placed to help somebody who is inclined to write an /etc/magic\nentry to detect files of format-patch output type if you use the scissors\nformat.\n\nOne thing that we probably would want to clarify is use of the \"From:\" and\nthe \"Subject:\" fields after the scissors in such a context.\n\n\"How about this patch?\" is most likely to be written by the same person as\nthe message is coming from, so I think you would rarely need a \"From:\"\nafter the scissors. On the other hand, in such a message, you would come\nup with a potential solution to a problem raised in a discussion, and the\noriginal subject would likely to be about a description of the problem or\na request for help, while the patch title would be about the solution, so\nit is very likely that you would want to have a \"Subject:\" line after the\nscissors.\n\nScissors can run in either direction; I am right handed and tend to write\nthem as \"-- >8 --\", but your example is for a left handed person. Either\nis fine.\n\nOther than that, looks good to me.\n"},{"id":"165849","messageId":"20110414211125.GA15277@elie","threadId":"27088","inReplyTo":"7vzkntkc9d.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] Documentation: summarize how format-patch output is consumed","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-14T21:11:25Z","receivedAt":"2011-04-14T21:11:25Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Add a DISCUSSION section to encourage people to send patches in a\nform that can be applied by \"git am\" automatically. There are two\nsuch forms:\n\n 1. The default form in which most metadata goes in the mail header\n and the message body starts with the patch description;\n\n 2. The snipsnip form in which a message starts with pertinent\n discussion and ends with a patch after a \"scissors\" mark.\n\nUse an example requiring QP encoding in the \"Subject:\" field intended\nfor the mailer, to give the reader a chance to reflect on that (rather\nthan being startled later). By contrast, in-body \"From:\" and\n\"Subject:\" lines should be human-readable and not QP encoded.\n\nA patch following \"How about this patch?\" is most likely to be written\nby the same person as the message is coming from, so you would rarely\nneed a \"From:\" after the scissors. On the other hand, such a message\ntypically presents a potential solution to a problem raised in\ndiscussion and the original subject is likely to be a description of\nthe problem or a request for help while the patch title is about the\nsolution, so it is very likely that you would want a \"Subject:\" line\nafter the scissors. It would be nice to clarify use of the \"From:\",\n\"Date:\", and \"Subject:\" fields after the scissors in general, but this\npatch avoids the topic in hope of leading the reader to look to\ngit-am(1) for a detailed discussion.\n\nWhile at it, include a pointer to Documentation/SubmittingPatches\nfor MUA-specific hints.\n\nInspired-by: Jim Meyering \nSigned-off-by: Jonathan Nieder \nImproved-by: Junio C Hamano \n---\nJunio C Hamano wrote:\n\n> It still is preferred to remove the magic \"From xxxx Mon Sep 17 00:00:00\n> 2001\" we placed to help somebody who is inclined to write an /etc/magic\n> entry to detect files of format-patch output type if you use the scissors\n> format.\n[and many useful suggestions]\n\nThanks. Changes since v1:\n\n - no more inline \"From:\" field\n - different patch to demonstrate qp-encoding in \"Subject:\" instead\n - use right-handed scissors\n\nI didn't find a way to sneak in a comment about \"file\" magic; that can\ncome another day.\n\n Documentation/git-format-patch.txt | 50 +++++++++++++++++++++++++++++++++++-\n 1 files changed, 49 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex a5525e9..875ea9b 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -274,9 +274,57 @@ as e-mailable patches:\n $ git format-patch -3\n ------------\n \n+DISCUSSION\n+----------\n+The patch produced by 'git format-patch' is in UNIX mailbox format,\n+like so:\n+\n+------------\n+From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001\n+From: Tony Luck \n+Date: Tue, 13 Jul 2010 11:42:54 -0700\n+Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=\n+ =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=\n+MIME-Version: 1.0\n+Content-Type: text/plain; charset=UTF-8\n+Content-Transfer-Encoding: 8bit\n+\n+arch/arm config files were slimmed down using a python script\n+(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)\n+\n+Do the same for ia64 so we can have sleek & trim looking\n+...\n+------------\n+\n+Typically it will be placed in a MUA's drafts folder, edited to add\n+timely commentary that should not go in the changelog after the three\n+dashes, and then sent as a message whose body starts with \"arch/arm\n+config files were\". On the receiving end, readers can save\n+interesting patches in a UNIX mailbox and apply them with\n+linkgit:git-am[1].\n+\n+'git am --scissors' accepts an alternative format with the patch\n+inline in the message:\n+\n+------------\n+...\n+> So we should do such-and-such.\n+\n+Makes sense to me. How about this patch?\n+\n+-- >8 --\n+Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet\n+\n+arch/arm config files were slimmed down using a python script\n+...\n+------------\n+\n+See linkgit:git-am[1] for details.\n+\n SEE ALSO\n --------\n-linkgit:git-am[1], linkgit:git-send-email[1]\n+linkgit:git-am[1], linkgit:git-send-email[1], linkgit:git-imap-send[1],\n+Documentation/SubmittingPatches\n \n GIT\n ---\n-- \n1.7.5.rc0\n"},{"id":"165856","messageId":"7vlizcfpz8.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"20110414211125.GA15277@elie","subject":"Re: [PATCH v2] Documentation: summarize how format-patch output is consumed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-14T22:05:47Z","receivedAt":"2011-04-14T22:05:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> It would be nice to clarify use of the \"From:\",\n> \"Date:\", and \"Subject:\" fields after the scissors in general, but this\n> patch avoids the topic in hope of leading the reader to look to\n> git-am(1) for a detailed discussion.\n\nThat is going backwards. The new discussion section is to help people who\nsend e-mails using the output of this command, and the information you are\nleaving out is more useful to these people to decide what to cut and what\nto keep. The users of \"am\" do not have make the choice to begin with.\n\n> I didn't find a way to sneak in a comment about \"file\" magic; that can\n> come another day.\n\nHeh, you could have done something like:\n\n> +DISCUSSION\n> +----------\n> +The patch produced by 'git format-patch' is in UNIX mailbox format,\n> +like so:\n\n -like so:\n +with a fixed \"magic\" datestamp to help people recognize that such a file\n +is an output from format-patch and not a real mailbox, like so:\n\nif you really wanted to ;-).\n\n> +Typically it will be placed in a MUA's drafts folder, edited to add\n> +timely commentary that should not go in the changelog after the three\n> +dashes, and then sent as a message whose body starts with \"arch/arm\n> +config files were\". On the receiving end, readers can save\n> +interesting patches in a UNIX mailbox and apply them with\n> +linkgit:git-am[1].\n\nGood. I would suggest rephrasing the next paragraph, though.\n\n> +'git am --scissors' accepts an alternative format with the patch\n> +inline in the message:\n\n-'git am --scissors' accepts an alternative format with the patch\n-inline in the message:\n+When sending a patch as part of an ongoing discussion, the patch generated\n+by 'git format-patch' can be to take advantage of `git am --scissors`\n+feature. After writing your response to the discussion, write a line that\n+consists solely of \"-- >8 --\" (scissors), append the patch, and remove\n+unnecessary header fields, like this:\n\n> +------------\n> +...\n> +> So we should do such-and-such.\n> +\n> +Makes sense to me. How about this patch?\n> +\n> +-- >8 --\n> +Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet\n> +\n> +arch/arm config files were slimmed down using a python script\n> +...\n> +------------\n\n+Note that when used this way, most often you are sending your own patch,\n+so you should omit From: and Date: lines from the patch file, together\n+with the \"From $SHA-1 $magic_timestamp\" marker. Also your patch title\n+is likely to be different from the subject of the discussion you are\n+sending this response to, so it is likely that you would want to keep the\n+Subject: line, like the example above.\n+\n\n> +See linkgit:git-am[1] for details.\n> +\n\n> -linkgit:git-am[1], linkgit:git-send-email[1]\n> +linkgit:git-am[1], linkgit:git-send-email[1], linkgit:git-imap-send[1],\n> +Documentation/SubmittingPatches\n\nHmm, I suspect this is (1) bad because the end users without the source\nmay not have access to it, and (2) bad because it may indicate that there\nare hints and tricks in SubmittingPatches file, which narrowly targets\ndevelopers of this project, but they would also be helpful to the general\naudience. Perhaps some text needs moving from there to here?\n"},{"id":"165868","messageId":"20110415021100.GA19829@elie","threadId":"27088","inReplyTo":"7vlizcfpz8.fsf@alter.siamese.dyndns.org","subject":"[PATCH/RFC v3 0/5] Documentation/format-patch: more hints on submitting patches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:11:00Z","receivedAt":"2011-04-15T02:11:00Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> -linkgit:git-am[1], linkgit:git-send-email[1]\n>> +linkgit:git-am[1], linkgit:git-send-email[1], linkgit:git-imap-send[1],\n>> +Documentation/SubmittingPatches\n>\n> Hmm, I suspect this is (1) bad because the end users without the source\n> may not have access to it, and (2) bad because it may indicate that there\n> are hints and tricks in SubmittingPatches file, which narrowly targets\n> developers of this project, but they would also be helpful to the general\n> audience. Perhaps some text needs moving from there to here?\n\nYep, true. How about this?\n\nPatch 1 explains the \"canonical\" and \"with scissors\" formats of mails\nwith patches. It's basically the same as before, except with lots of\nnice suggestions from Junio incorporated.\n\nPatch 2 explains how new patch submitters can test their tools before\nunleashing them on the world. It should be common sense, but... The\ntext is taken from Documentation/SubmittingPatches.\n\nPatch 3 is rough; it exposes the Thunderbird MUA-specific hints. Help\nmaking it accurate and consistent with git-imap-send(1) would be very\nmuch appreciated\n\nPatch 4 contains KMail hints from SubmittingPatches; help would\nappreciated in making sure that's still accurate, too.\n\nPatch 5 contains the famous GMail hints, finally spreading them out\nin EXAMPLES sections where they belong.\n\nMaybe this can be a good starting point for future changes.\n\nJonathan Nieder (5):\n Documentation: describe the format of messages with inline patches\n Documentation: explain how to check for patch corruption\n Documentation: hints for sending patches inline with Thunderbird\n Documentation: publicize KMail hints for sending patches inline\n Documentation: publicize hints for sending patches with GMail\n\n Documentation/SubmittingPatches | 207 +++-------------------------------\n Documentation/git-format-patch.txt | 217 ++++++++++++++++++++++++++++++++++++\n Documentation/git-imap-send.txt | 29 +++++\n Documentation/git-send-email.txt | 19 +++-\n 4 files changed, 277 insertions(+), 195 deletions(-)\n"},{"id":"165869","messageId":"20110415022202.GB19829@elie","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH 1/5] Documentation: describe the format of messages with inline patches","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:22:02Z","receivedAt":"2011-04-15T02:22:02Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Add a DISCUSSION section to the \"git format-patch\" manual to encourage\npeople to send patches in a form that can be applied by \"git am\"\nautomatically. There are two such forms:\n\n 1. The default form in which most metadata goes in the mail header\n and the message body starts with the patch description;\n\n 2. The snipsnip form in which a message starts with pertinent\n discussion and ends with a patch after a \"scissors\" mark.\n\nThe example requires QP encoding in the \"Subject:\" header intended for\nthe mailer to give the reader a chance to reflect on that, rather than\nbeing startled by it later. By contrast, in-body \"From:\" and\n\"Subject:\" lines should be human-readable and not QP encoded.\n\nInspired-by: Jim Meyering \nSigned-off-by: Jonathan Nieder \nImproved-by: Junio C Hamano \n---\n Documentation/git-format-patch.txt | 58 ++++++++++++++++++++++++++++++++++++\n 1 files changed, 58 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex a5525e9..a4a9813 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -229,6 +229,64 @@ attachments, and sign off patches with configuration variables.\n ------------\n \n \n+DISCUSSION\n+----------\n+\n+The patch produced by 'git format-patch' is in UNIX mailbox format,\n+with a fixed \"magic\" time stamp to indicate that the file is output\n+from format-patch rather than a real mailbox, like so:\n+\n+------------\n+From 8f72bad1baf19a53459661343e21d6491c3908d3 Mon Sep 17 00:00:00 2001\n+From: Tony Luck \n+Date: Tue, 13 Jul 2010 11:42:54 -0700\n+Subject: [PATCH] =?UTF-8?q?[IA64]=20Put=20ia64=20config=20files=20on=20the=20?=\n+ =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20diet?=\n+MIME-Version: 1.0\n+Content-Type: text/plain; charset=UTF-8\n+Content-Transfer-Encoding: 8bit\n+\n+arch/arm config files were slimmed down using a python script\n+(See commit c2330e286f68f1c408b4aa6515ba49d57f05beae comment)\n+\n+Do the same for ia64 so we can have sleek & trim looking\n+...\n+------------\n+\n+Typically it will be placed in a MUA's drafts folder, edited to add\n+timely commentary that should not go in the changelog after the three\n+dashes, and then sent as a message whose body starts with \"arch/arm\n+config files were\". On the receiving end, readers can save\n+interesting patches in a UNIX mailbox and apply them with\n+linkgit:git-am[1].\n+\n+When a patch is part of an ongoing discussion, the patch generated by\n+'git format-patch' can be tweaked to take advantage of the 'git am\n+--scissors' feature. After your response to the discussion comes a\n+line that consists solely of \"`-- >8 --`\" (scissors and perforation),\n+followed by the patch with unnecessary header fields removed:\n+\n+------------\n+...\n+> So we should do such-and-such.\n+\n+Makes sense to me. How about this patch?\n+\n+-- >8 --\n+Subject: [IA64] Put ia64 config files on the Uwe Kleine-König diet\n+\n+arch/arm config files were slimmed down using a python script\n+...\n+------------\n+\n+When sending a patch this way, most often you are sending your own\n+patch, so in addition to the \"`From $SHA1 $magic_timestamp`\" marker you\n+should omit `From:` and `Date:` lines from the patch file. The patch\n+title is likely to be different from the subject of the discussion the\n+patch is in response to, so it is likely that you would want to keep\n+the Subject: line, like the example above.\n+\n+\n EXAMPLES\n --------\n \n-- \n1.7.5.rc0\n"},{"id":"165870","messageId":"20110415022401.GC19829@elie","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH 2/5] Documentation: explain how to check for patch corruption","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:24:01Z","receivedAt":"2011-04-15T02:24:01Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"SubmittingPatches has some excellent advice about how to check a patch\nfor corruption before sending it off. Move it to the format-patch\nmanual so it can be installed with git's documentation for use by\npeople not necessarily interested in the git project's practices.\n\nSigned-off-by: Jonathan Nieder \n---\n Documentation/SubmittingPatches | 58 ++++++++---------------------------\n Documentation/git-format-patch.txt | 46 ++++++++++++++++++++++++++++\n 2 files changed, 60 insertions(+), 44 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex c6a5032..20b4101 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -344,50 +344,20 @@ MUA specific hints\n \n Some of patches I receive or pick up from the list share common\n patterns of breakage. Please make sure your MUA is set up\n-properly not to corrupt whitespaces. Here are two common ones\n-I have seen:\n-\n-* Empty context lines that do not have _any_ whitespace.\n-\n-* Non empty context lines that have one extra whitespace at the\n- beginning.\n-\n-One test you could do yourself if your MUA is set up correctly is:\n-\n-* Send the patch to yourself, exactly the way you would, except\n- To: and Cc: lines, which would not contain the list and\n- maintainer address.\n-\n-* Save that patch to a file in UNIX mailbox format. Call it say\n- a.patch.\n-\n-* Try to apply to the tip of the \"master\" branch from the\n- git.git public repository:\n-\n- $ git fetch http://kernel.org/pub/scm/git/git.git master:test-apply\n- $ git checkout test-apply\n- $ git reset --hard\n- $ git am a.patch\n-\n-If it does not apply correctly, there can be various reasons.\n-\n-* Your patch itself does not apply cleanly. That is _bad_ but\n- does not have much to do with your MUA. Please rebase the\n- patch appropriately.\n-\n-* Your MUA corrupted your patch; \"am\" would complain that\n- the patch does not apply. Look at .git/rebase-apply/ subdirectory and\n- see what 'patch' file contains and check for the common\n- corruption patterns mentioned above.\n-\n-* While you are at it, check what are in 'info' and\n- 'final-commit' files as well. If what is in 'final-commit' is\n- not exactly what you would want to see in the commit log\n- message, it is very likely that your maintainer would end up\n- hand editing the log message when he applies your patch.\n- Things like \"Hi, this is my first patch.\\n\", if you really\n- want to put in the patch e-mail, should come after the\n- three-dash line that signals the end of the commit message.\n+properly not to corrupt whitespaces.\n+\n+See the DISCUSSION section of git-format-patch(1) for hints on\n+checking your patch by mailing it to yourself and applying with\n+git-am(1).\n+\n+While you are at it, check the resulting commit log message from\n+a trial run of applying the patch. If what is in the resulting\n+commit is not exactly what you would want to see, it is very\n+likely that your maintainer would end up hand editing the log\n+message when he applies your patch. Things like \"Hi, this is my\n+first patch.\\n\", if you really want to put in the patch e-mail,\n+should come after the three-dash line that signals the end of the\n+commit message.\n \n \n Pine\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex a4a9813..5c60418 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -286,6 +286,52 @@ title is likely to be different from the subject of the discussion the\n patch is in response to, so it is likely that you would want to keep\n the Subject: line, like the example above.\n \n+Checking for patch corruption\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+Many mailers if not set up properly will corrupt whitespace. Here are\n+two common types of corruption:\n+\n+* Empty context lines that do not have _any_ whitespace.\n+\n+* Non-empty context lines that have one extra whitespace at the\n+ beginning.\n+\n+One way to test if your MUA is set up correctly is:\n+\n+* Send the patch to yourself, exactly the way you would, except\n+ with To: and Cc: lines that do not contain the list and\n+ maintainer address.\n+\n+* Save that patch to a file in UNIX mailbox format. Call it a.patch,\n+ say.\n+\n+* Apply it:\n+\n+ $ git fetch master:test-apply\n+ $ git checkout test-apply\n+ $ git reset --hard\n+ $ git am a.patch\n+\n+If it does not apply correctly, there can be various reasons.\n+\n+* The patch itself does not apply cleanly. That is _bad_ but\n+ does not have much to do with your MUA. You might want to rebase\n+ the patch with linkgit:git-rebase[1] before regenerating it in\n+ this case.\n+\n+* The MUA corrupted your patch; \"am\" would complain that\n+ the patch does not apply. Look in the .git/rebase-apply/ subdirectory and\n+ see what 'patch' file contains and check for the common\n+ corruption patterns mentioned above.\n+\n+* While at it, check the 'info' and 'final-commit' files as well.\n+ If what is in 'final-commit' is not exactly what you would want to\n+ see in the commit log message, it is very likely that the\n+ receiver would end up hand editing the log message when applying\n+ your patch. Things like \"Hi, this is my first patch.\\n\" in the\n+ patch e-mail should come after the three-dash line that signals\n+ the end of the commit message.\n+\n \n EXAMPLES\n --------\n-- \n1.7.5.rc0\n"},{"id":"165871","messageId":"20110415022806.GD19829@elie","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH 3/5] Documentation: hints for sending patches inline with Thunderbird","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:28:06Z","receivedAt":"2011-04-15T02:28:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The standard reference for this information is the article\n\"Plain text e-mail - Thunderbird#Completely_plain_email\" at\nkb.mozillazine.org, but the hints hidden away in git's\nSubmittingPatches file are more complete. Move them to the\n\"git format-patch\" manual so they can be installed with git and\nread by a wide audience.\n\nWhile at it, make some tweaks:\n\n - update \"Approach #1\" so it might work with Thunderbird 3;\n - remove ancient version numbers from the descriptions of both\n approaches so current readers might have more reason to\n complain if they don't work.\n\nSigned-off-by: Jonathan Nieder \n---\nAs mentioned in the cover letter, this is rough. Help making it\naccurate and consistent with git-imap-send(1) would be very much\nappreciated.\n\n Documentation/SubmittingPatches | 81 +----------------------------------\n Documentation/git-format-patch.txt | 83 ++++++++++++++++++++++++++++++++++++\n 2 files changed, 84 insertions(+), 80 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 20b4101..7908119 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -416,86 +416,7 @@ it.\n Thunderbird\n -----------\n \n-(A Large Angry SCM)\n-\n-By default, Thunderbird will both wrap emails as well as flag them as\n-being 'format=flowed', both of which will make the resulting email unusable\n-by git.\n-\n-Here are some hints on how to successfully submit patches inline using\n-Thunderbird.\n-\n-There are two different approaches. One approach is to configure\n-Thunderbird to not mangle patches. The second approach is to use\n-an external editor to keep Thunderbird from mangling the patches.\n-\n-Approach #1 (configuration):\n-\n-This recipe is current as of Thunderbird 2.0.0.19. Three steps:\n- 1. Configure your mail server composition as plain text\n- Edit...Account Settings...Composition & Addressing,\n- uncheck 'Compose Messages in HTML'.\n- 2. Configure your general composition window to not wrap\n- Edit..Preferences..Composition, wrap plain text messages at 0\n- 3. Disable the use of format=flowed\n- Edit..Preferences..Advanced..Config Editor. Search for:\n- mailnews.send_plaintext_flowed\n- toggle it to make sure it is set to 'false'.\n-\n-After that is done, you should be able to compose email as you\n-otherwise would (cut + paste, git-format-patch | git-imap-send, etc),\n-and the patches should not be mangled.\n-\n-Approach #2 (external editor):\n-\n-This recipe appears to work with the current [*1*] Thunderbird from Suse.\n-\n-The following Thunderbird extensions are needed:\n-\tAboutConfig 0.5\n-\t\thttp://aboutconfig.mozdev.org/\n-\tExternal Editor 0.7.2\n-\t\thttp://globs.org/articles.php?lng=en&pg=8\n-\n-1) Prepare the patch as a text file using your method of choice.\n-\n-2) Before opening a compose window, use Edit->Account Settings to\n-uncheck the \"Compose messages in HTML format\" setting in the\n-\"Composition & Addressing\" panel of the account to be used to send the\n-patch. [*2*]\n-\n-3) In the main Thunderbird window, _before_ you open the compose window\n-for the patch, use Tools->about:config to set the following to the\n-indicated values:\n-\tmailnews.send_plaintext_flowed\t=> false\n-\tmailnews.wraplength\t\t=> 0\n-\n-4) Open a compose window and click the external editor icon.\n-\n-5) In the external editor window, read in the patch file and exit the\n-editor normally.\n-\n-6) Back in the compose window: Add whatever other text you wish to the\n-message, complete the addressing and subject fields, and press send.\n-\n-7) Optionally, undo the about:config/account settings changes made in\n-steps 2 & 3.\n-\n-\n-[Footnotes]\n-*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse\n-9.3 professional updates.\n-\n-*2* It may be possible to do this with about:config and the following\n-settings but I haven't tried, yet.\n-\tmail.html_compose\t\t\t=> false\n-\tmail.identity.default.compose_html\t=> false\n-\tmail.identity.id?.compose_html\t\t=> false\n-\n-(Lukas Sandström)\n-\n-There is a script in contrib/thunderbird-patch-inline which can help\n-you include patches with Thunderbird in an easy way. To use it, do the\n-steps above and then use the script as the external editor.\n+See the MUA-SPECIFIC HINTS section of git-format-patch(1).\n \n Gnus\n ----\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 5c60418..cbf2b9c 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -332,6 +332,89 @@ If it does not apply correctly, there can be various reasons.\n patch e-mail should come after the three-dash line that signals\n the end of the commit message.\n \n+MUA-SPECIFIC HINTS\n+------------------\n+Here are some hints on how to successfully submit patches inline using\n+various mailers.\n+\n+Thunderbird\n+~~~~~~~~~~~\n+By default, Thunderbird will both wrap emails as well as flag\n+them as being 'format=flowed', both of which will make the\n+resulting email unusable by git.\n+\n+There are two different approaches. One approach is to configure\n+Thunderbird to not mangle patches. The second approach is to use\n+an external editor to keep Thunderbird from mangling the patches.\n+\n+Approach #1 (configuration)\n+^^^^^^^^^^^^^^^^^^^^^^^^^^^\n+Three steps:\n+\n+1. Configure your mail server composition as plain text:\n+ Edit...Account Settings...Composition & Addressing,\n+ uncheck \"Compose Messages in HTML\".\n+\n+2. Configure your general composition window to not wrap.\n++\n+In Thunderbird 2:\n+Edit..Preferences..Composition, wrap plain text messages at 0\n++\n+In Thunderbird 3:\n+Edit..Preferences..Advanced..Config Editor. Search for\n+\"mail.wrap_long_lines\".\n+Toggle it to make sure it is set to `false`.\n+\n+3. Disable the use of format=flowed:\n+Edit..Preferences..Advanced..Config Editor. Search for\n+\"mailnews.send_plaintext_flowed\".\n+Toggle it to make sure it is set to `false`.\n+\n+After that is done, you should be able to compose email as you\n+otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),\n+and the patches will not be mangled.\n+\n+Approach #2 (external editor)\n+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n+\n+The following Thunderbird extensions are needed:\n+AboutConfig from http://aboutconfig.mozdev.org/ and\n+External Editor from http://globs.org/articles.php?lng=en&pg=8\n+\n+1. Prepare the patch as a text file using your method of choice.\n+\n+2. Before opening a compose window, use Edit->Account Settings to\n+ uncheck the \"Compose messages in HTML format\" setting in the\n+ \"Composition & Addressing\" panel of the account to be used to\n+ send the patch.\n+\n+3. In the main Thunderbird window, 'before' you open the compose\n+ window for the patch, use Tools->about:config to set the\n+ following to the indicated values:\n++\n+----------\n+\tmailnews.send_plaintext_flowed => false\n+\tmailnews.wraplength => 0\n+----------\n+\n+4. Open a compose window and click the external editor icon.\n+\n+5. In the external editor window, read in the patch file and exit\n+ the editor normally.\n+\n+Side note: it may be possible to do step 2 with\n+about:config and the following settings but no one's tried yet.\n+\n+----------\n+\tmail.html_compose => false\n+\tmail.identity.default.compose_html => false\n+\tmail.identity.id?.compose_html => false\n+----------\n+\n+There is a script in contrib/thunderbird-patch-inline which can help\n+you include patches with Thunderbird in an easy way. To use it, do the\n+steps above and then use the script as the external editor.\n+\n \n EXAMPLES\n --------\n-- \n1.7.5.rc0\n"},{"id":"165872","messageId":"20110415023255.GE19829@elie","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH 4/5] Documentation: publicize KMail hints for sending patches inline","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:32:55Z","receivedAt":"2011-04-15T02:32:55Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"These hints are in git's private SubmittingPatches document but a\nwider audience might be interested. Move them to the \"git\nformat-patch\" manpage.\n\nI'm not sure what gotchas these hints are meant to work around.\nThey might be completely false.\n\nSigned-off-by: Jonathan Nieder \n---\nA quick search for \"how to send patches with KMail\" gave me the\n\"external editor\" trick. Do these instructions work? ;-)\n\nAnyway, this patch reuses the current instructions from\nSubmittingPatches as-is.\n\n Documentation/SubmittingPatches | 22 ++--------------------\n Documentation/git-format-patch.txt | 16 ++++++++++++++++\n 2 files changed, 18 insertions(+), 20 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex 7908119..e9d8c3f 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -413,8 +413,8 @@ that or Gentoo did it.) So you need to set the\n it.\n \n \n-Thunderbird\n------------\n+Thunderbird, KMail\n+------------------\n \n See the MUA-SPECIFIC HINTS section of git-format-patch(1).\n \n@@ -433,24 +433,6 @@ message in raw form before using '|' to run the pipe can work\n this problem around.\n \n \n-KMail\n------\n-\n-This should help you to submit patches inline using KMail.\n-\n-1) Prepare the patch as a text file.\n-\n-2) Click on New Mail.\n-\n-3) Go under \"Options\" in the Composer window and be sure that\n-\"Word wrap\" is not set.\n-\n-4) Use Message -> Insert file... and insert the patch.\n-\n-5) Back in the compose window: add whatever other text you wish to the\n-message, complete the addressing and subject fields, and press send.\n-\n-\n Gmail\n -----\n \ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex cbf2b9c..8887375 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -415,6 +415,22 @@ There is a script in contrib/thunderbird-patch-inline which can help\n you include patches with Thunderbird in an easy way. To use it, do the\n steps above and then use the script as the external editor.\n \n+KMail\n+~~~~~\n+This should help you to submit patches inline using KMail.\n+\n+1. Prepare the patch as a text file.\n+\n+2. Click on New Mail.\n+\n+3. Go under \"Options\" in the Composer window and be sure that\n+ \"Word wrap\" is not set.\n+\n+4. Use Message -> Insert file... and insert the patch.\n+\n+5. Back in the compose window: add whatever other text you wish to the\n+ message, complete the addressing and subject fields, and press send.\n+\n \n EXAMPLES\n --------\n-- \n1.7.5.rc0\n"},{"id":"165873","messageId":"20110415023357.GF19829@elie","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH 5/5] Documentation: publicize hints for sending patches with GMail","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T02:33:57Z","receivedAt":"2011-04-15T02:33:57Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"The hints in SubmittingPatches about stopping GMail from clobbering\npatches are widely useful both as examples of \"git send-email\" and\n\"git imap-send\" usage.\n\nMove the documentation to the appropriate places.\n\nWhile at it, don't encourage storing passwords in config files.\n\nSigned-off-by: Jonathan Nieder \n---\nThat's the end of the series. Thoughts welcome as always.\n\n Documentation/SubmittingPatches | 54 +----------------------------------\n Documentation/git-format-patch.txt | 14 +++++++++\n Documentation/git-imap-send.txt | 29 +++++++++++++++++++\n Documentation/git-send-email.txt | 19 ++++++++++--\n 4 files changed, 61 insertions(+), 55 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex e9d8c3f..938eccf 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -413,8 +413,8 @@ that or Gentoo did it.) So you need to set the\n it.\n \n \n-Thunderbird, KMail\n-------------------\n+Thunderbird, KMail, GMail\n+-------------------------\n \n See the MUA-SPECIFIC HINTS section of git-format-patch(1).\n \n@@ -431,53 +431,3 @@ characters (most notably in people's names), and also\n whitespaces (fatal in patches). Running 'C-u g' to display the\n message in raw form before using '|' to run the pipe can work\n this problem around.\n-\n-\n-Gmail\n------\n-\n-GMail does not appear to have any way to turn off line wrapping in the web\n-interface, so this will mangle any emails that you send. You can however\n-use \"git send-email\" and send your patches through the GMail SMTP server, or\n-use any IMAP email client to connect to the google IMAP server and forward\n-the emails through that.\n-\n-To use \"git send-email\" and send your patches through the GMail SMTP server,\n-edit ~/.gitconfig to specify your account settings:\n-\n-[sendemail]\n-\tsmtpencryption = tls\n-\tsmtpserver = smtp.gmail.com\n-\tsmtpuser = user@gmail.com\n-\tsmtppass = p4ssw0rd\n-\tsmtpserverport = 587\n-\n-Once your commits are ready to be sent to the mailing list, run the\n-following commands:\n-\n- $ git format-patch --cover-letter -M origin/master -o outgoing/\n- $ edit outgoing/0000-*\n- $ git send-email outgoing/*\n-\n-To submit using the IMAP interface, first, edit your ~/.gitconfig to specify your\n-account settings:\n-\n-[imap]\n-\tfolder = \"[Gmail]/Drafts\"\n-\thost = imaps://imap.gmail.com\n-\tuser = user@gmail.com\n-\tpass = p4ssw0rd\n-\tport = 993\n-\tsslverify = false\n-\n-You might need to instead use: folder = \"[Google Mail]/Drafts\" if you get an error\n-that the \"Folder doesn't exist\".\n-\n-Once your commits are ready to be sent to the mailing list, run the\n-following commands:\n-\n- $ git format-patch --cover-letter -M --stdout origin/master | git imap-send\n-\n-Just make sure to disable line wrapping in the email client (GMail web\n-interface will line wrap no matter what, so you need to use a real\n-IMAP client).\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 8887375..c44e248 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -337,6 +337,20 @@ MUA-SPECIFIC HINTS\n Here are some hints on how to successfully submit patches inline using\n various mailers.\n \n+GMail\n+~~~~~\n+GMail does not have any way to turn off line wrapping in the web\n+interface, so it will mangle any emails that you send. You can however\n+use \"git send-email\" and send your patches through the GMail SMTP server, or\n+use any IMAP email client to connect to the google IMAP server and forward\n+the emails through that.\n+\n+For hints on using 'git send-email' to send your patches through the\n+GMail SMTP server, see the EXAMPLE section of linkgit:git-send-email[1].\n+\n+For hints on submission using the IMAP interface, see the EXAMPLE\n+section of linkgit:git-imap-send[1].\n+\n Thunderbird\n ~~~~~~~~~~~\n By default, Thunderbird will both wrap emails as well as flag\ndiff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt\nindex d3013d6..4e09708 100644\n--- a/Documentation/git-imap-send.txt\n+++ b/Documentation/git-imap-send.txt\n@@ -111,6 +111,31 @@ Using direct mode with SSL:\n ..........................\n \n \n+EXAMPLE\n+-------\n+To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig\n+to specify your account settings:\n+\n+---------\n+[imap]\n+\tfolder = \"[Gmail]/Drafts\"\n+\thost = imaps://imap.gmail.com\n+\tuser = user@gmail.com\n+\tport = 993\n+\tsslverify = false\n+---------\n+\n+You might need to instead use: folder = \"[Google Mail]/Drafts\" if you get an error\n+that the \"Folder doesn't exist\".\n+\n+Once the commits are ready to be sent, run the following command:\n+\n+ $ git format-patch --cover-letter -M --stdout origin/master | git imap-send\n+\n+Just make sure to disable line wrapping in the email client (GMail's web\n+interface will wrap lines no matter what, so you need to use a real\n+IMAP client).\n+\n CAUTION\n -------\n It is still your responsibility to make sure that the email message\n@@ -124,6 +149,10 @@ Thunderbird in particular is known to be problematic. Thunderbird\n users may wish to visit this web page for more information:\n http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email\n \n+SEE ALSO\n+--------\n+linkgit:git-format-patch[1], linkgit:git-send-email[1], mbox(5)\n+\n GIT\n ---\n Part of the linkgit:git[1] suite\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex ee14f74..5a168cf 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -348,10 +348,12 @@ sendemail.confirm::\n \tone of 'always', 'never', 'cc', 'compose', or 'auto'. See '--confirm'\n \tin the previous section for the meaning of these values.\n \n+EXAMPLE\n+-------\n Use gmail as the smtp server\n-----------------------------\n-\n-Add the following section to the config file:\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+To use 'git send-email' to send your patches through the GMail SMTP server,\n+edit ~/.gitconfig to specify your account settings:\n \n \t[sendemail]\n \t\tsmtpencryption = tls\n@@ -359,9 +361,20 @@ Add the following section to the config file:\n \t\tsmtpuser = yourname@gmail.com\n \t\tsmtpserverport = 587\n \n+Once your commits are ready to be sent to the mailing list, run the\n+following commands:\n+\n+\t$ git format-patch --cover-letter -M origin/master -o outgoing/\n+\t$ edit outgoing/0000-*\n+\t$ git send-email outgoing/*\n+\n Note: the following perl modules are required\n Net::SMTP::SSL, MIME::Base64 and Authen::SASL\n \n+SEE ALSO\n+--------\n+linkgit:git-format-patch[1], linkgit:git-imap-send[1], mbox(5)\n+\n GIT\n ---\n Part of the linkgit:git[1] suite\n-- \n1.7.5.rc0\n"},{"id":"165879","messageId":"7vsjtkdsij.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"20110415022401.GC19829@elie","subject":"Re: [PATCH 2/5] Documentation: explain how to check for patch corruption","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-15T04:53:56Z","receivedAt":"2011-04-15T04:53:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> SubmittingPatches has some excellent advice about how to check a patch\n> for corruption before sending it off. Move it to the format-patch\n> manual so it can be installed with git's documentation for use by\n> people not necessarily interested in the git project's practices.\n>\n> Signed-off-by: Jonathan Nieder \n> ---\n> Documentation/SubmittingPatches | 58 ++++++++---------------------------\n> Documentation/git-format-patch.txt | 46 ++++++++++++++++++++++++++++\n> 2 files changed, 60 insertions(+), 44 deletions(-)\n>\n> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\n> index c6a5032..20b4101 100644\n> --- a/Documentation/SubmittingPatches\n> +++ b/Documentation/SubmittingPatches\n> @@ -344,50 +344,20 @@ MUA specific hints\n> \n> Some of patches I receive or pick up from the list share common\n> patterns of breakage. Please make sure your MUA is set up\n> +properly not to corrupt whitespaces.\n> +\n> +See the DISCUSSION section of git-format-patch(1) for hints on\n> +checking your patch by mailing it to yourself and applying with\n> +git-am(1).\n> +\n> +While you are at it, check the resulting commit log message from\n> +a trial run of applying the patch. If what is in the resulting\n> +commit is not exactly what you would want to see, it is very\n> +likely that your maintainer would end up hand editing the log\n> +message when he applies your patch. Things like \"Hi, this is my\n> +first patch.\\n\", if you really want to put in the patch e-mail,\n> +should come after the three-dash line that signals the end of the\n> +commit message.\n\nPerhaps the last paragraph can also go, as a copy of it now is in git-am(1)?\n\n> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\n> index a4a9813..5c60418 100644\n> --- a/Documentation/git-format-patch.txt\n> +++ b/Documentation/git-format-patch.txt\n> @@ -286,6 +286,52 @@ title is likely to be different from the subject\n> +One way to test if your MUA is set up correctly is:\n> +\n> +* Send the patch to yourself, exactly the way you would, except\n> + with To: and Cc: lines that do not contain the list and\n> + maintainer address.\n\n... \"except for removing other people from To: and Cc: lines to avoid\nspamming them with your test\"?\n"},{"id":"165880","messageId":"20110415061758.GA20441@elie","threadId":"27088","inReplyTo":"7vsjtkdsij.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/5] Documentation: explain how to check for patch corruption","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T06:17:58Z","receivedAt":"2011-04-15T06:17:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> +++ b/Documentation/SubmittingPatches\n[...]\n>> +While you are at it, check the resulting commit log message from\n>> +a trial run of applying the patch. If what is in the resulting\n[...]\n> Perhaps the last paragraph can also go, as a copy of it now is in git-am(1)?\n\nYes, good idea. I wanted to keep a reminder to look over the\nresulting commit (and especially its log message), but this section is\ndefinitely not the place.\n\n>> +++ b/Documentation/git-format-patch.txt\n>> @@ -286,6 +286,52 @@ title is likely to be different from the subject\n>> +One way to test if your MUA is set up correctly is:\n>> +\n>> +* Send the patch to yourself, exactly the way you would, except\n>> + with To: and Cc: lines that do not contain the list and\n>> + maintainer address.\n>\n> ... \"except for removing other people from To: and Cc: lines to avoid\n> spamming them with your test\"?\n\nYes, that is much clearer. If you'd like, I can collect other\ncorrections and read it over again myself to resend tomorrow.\n"},{"id":"165883","messageId":"4DA7F6C0.4050707@viscovery.net","threadId":"27088","inReplyTo":"20110415021100.GA19829@elie","subject":"[PATCH/RFC 6/5] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-04-15T07:41:52Z","receivedAt":"2011-04-15T07:41:52Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nSigned-off-by: Johannes Sixt \n---\n How about this as 6/5? I used the method described for this submission, so if\n what you got is unusable, you know what to think of the suggestion ;)\n\n I put this suggestion as approach #1 because I think it is superior to the\n other two (iff it worked).\n\n -- Hannes\n\n Documentation/git-format-patch.txt | 18 ++++++++++++++----\n 1 files changed, 14 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -343,11 +343,21 @@ By default, Thunderbird will both wrap emails as well as flag\n them as being 'format=flowed', both of which will make the\n resulting email unusable by git.\n \n-There are two different approaches. One approach is to configure\n-Thunderbird to not mangle patches. The second approach is to use\n+There are three different approaches: use an add-on to turn off line wraps,\n+configure Thunderbird to not mangle patches, or use\n an external editor to keep Thunderbird from mangling the patches.\n \n-Approach #1 (configuration)\n+Approach #1 (add-on)\n+^^^^^^^^^^^^^^^^^^^^\n+\n+Install the Toggle Word Wrap add-on that is available from\n+https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/\n+It adds a menu entry \"Enable Word Wrap\" that you can tick off. Now you\n+can compose the message as you otherwise do (cut + paste,\n+'git format-patch' | 'git imap-send', etc), but you have to insert\n+line breaks manually in any additional text that you type.\n+\n+Approach #2 (configuration)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n Three steps:\n \n@@ -374,7 +384,7 @@ After that is done, you should be able to compose email as you\n otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),\n and the patches will not be mangled.\n \n-Approach #2 (external editor)\n+Approach #3 (external editor)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n \n The following Thunderbird extensions are needed:\n"},{"id":"165916","messageId":"7vtydzcse4.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"4DA7F6C0.4050707@viscovery.net","subject":"Re: [PATCH/RFC 6/5] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-15T17:54:11Z","receivedAt":"2011-04-15T17:54:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> From: Johannes Sixt \n>\n> Signed-off-by: Johannes Sixt \n> ---\n> How about this as 6/5? I used the method described for this submission, so if\n> what you got is unusable, you know what to think of the suggestion ;)\n\nIt seems to apply fine ;-).\n\n> I put this suggestion as approach #1 because I think it is superior to the\n> other two (iff it worked).\n\nCare to reword \"superior\" in a less subjective way (which should be very\neasy --- both existing suggestions seem to force plain-text no-wrap on any\nand all outgoing mails and to make it cumbersome to flip back and forth,\nas opposed to this one that gives a one-click on-demand way to do so only\nwhen you are sending a patch) and put it in the log message?\n"},{"id":"165917","messageId":"4DA887FF.4070606@drmicha.warpmail.net","threadId":"27088","inReplyTo":"7vtydzcse4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC 6/5] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-15T18:01:35Z","receivedAt":"2011-04-15T18:01:35Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 15.04.2011 19:54:\n> Johannes Sixt writes:\n> \n>> From: Johannes Sixt \n>>\n>> Signed-off-by: Johannes Sixt \n>> ---\n>> How about this as 6/5? I used the method described for this submission, so if\n>> what you got is unusable, you know what to think of the suggestion ;)\n> \n> It seems to apply fine ;-).\n> \n>> I put this suggestion as approach #1 because I think it is superior to the\n>> other two (iff it worked).\n> \n> Care to reword \"superior\" in a less subjective way (which should be very\n> easy --- both existing suggestions seem to force plain-text no-wrap on any\n> and all outgoing mails and to make it cumbersome to flip back and forth,\n> as opposed to this one that gives a one-click on-demand way to do so only\n> when you are sending a patch) and put it in the log message?\n\nDoes this add-on toggle \"format fl[oa]wed\" also? Otherwise you have to\nmake this is off also.\n\nBTW: \"AboutConfig\" was great while it was needed, but these days you can\naccess Thunderbird's about:config from the options.\n\nMichael\n"},{"id":"165921","messageId":"7vfwpjcpue.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"4DA887FF.4070606@drmicha.warpmail.net","subject":"Re: [PATCH/RFC 6/5] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-15T18:49:13Z","receivedAt":"2011-04-15T18:49:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 15.04.2011 19:54:\n>> Johannes Sixt writes:\n>> \n>>> From: Johannes Sixt \n>>>\n>>> Signed-off-by: Johannes Sixt \n>>> ---\n>>> How about this as 6/5? I used the method described for this submission, so if\n>>> what you got is unusable, you know what to think of the suggestion ;)\n>> \n>> It seems to apply fine ;-).\n>> \n>>> I put this suggestion as approach #1 because I think it is superior to the\n>>> other two (iff it worked).\n>> \n>> Care to reword \"superior\" in a less subjective way (which should be very\n>> easy --- both existing suggestions seem to force plain-text no-wrap on any\n>> and all outgoing mails and to make it cumbersome to flip back and forth,\n>> as opposed to this one that gives a one-click on-demand way to do so only\n>> when you are sending a patch) and put it in the log message?\n> \n> Does this add-on toggle \"format fl[oa]wed\" also? Otherwise you have to\n> make this is off also.\n>\n> BTW: \"AboutConfig\" was great while it was needed, but these days you can\n> access Thunderbird's about:config from the options.\n\nI have no idea on neither of these two points, as I don't use these GUI\nthingies myself.\n"},{"id":"165927","messageId":"1302898291.5926.9.camel@drew-northup.unet.maine.edu","threadId":"27088","inReplyTo":"20110415022202.GB19829@elie","subject":"Re: [PATCH 1/5] Documentation: describe the format of messages with inline patches","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-04-15T20:11:31Z","receivedAt":"2011-04-15T20:11:31Z","isPatch":true,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Thu, 2011-04-14 at 21:22 -0500, Jonathan Nieder wrote:\n> Add a DISCUSSION section to the \"git format-patch\" manual to encourage\n> people to send patches in a form that can be applied by \"git am\"\n> automatically. There are two such forms:\n> \n> 1. The default form in which most metadata goes in the mail header\n> and the message body starts with the patch description;\n...\n> +DISCUSSION\n> +----------\n> +\n> +The patch produced by 'git format-patch' is in UNIX mailbox format,\n...\n> +\n> +arch/arm config files were slimmed down using a python script\n...\n> +Typically it will be placed in a MUA's drafts folder, edited to add\n> +timely commentary that should not go in the changelog after the three\n> +dashes, and then sent as a message whose body starts with \"arch/arm\n> +config files were\". On the receiving end, readers can save\n> +interesting patches in a UNIX mailbox and apply them with\n> +linkgit:git-am[1].\n\nMaybe I'm too picky, but I'd feel more comfortable saying:\n\n...\ndashes, and then sent as a message which in our example stars with\n\"arch/arm config files were...\" On the receiving end, readers can save\n...\n\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"165928","messageId":"20110415201706.GC13735@elie","threadId":"27088","inReplyTo":"4DA887FF.4070606@drmicha.warpmail.net","subject":"Re: [PATCH/RFC 6/5] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-15T20:17:06Z","receivedAt":"2011-04-15T20:17:06Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michael J Gruber wrote:\n\n> Does this add-on toggle \"format fl[oa]wed\" also?\n\nYep, it does. Great find, Hannes.\n\n> BTW: \"AboutConfig\" was great while it was needed, but these days you can\n> access Thunderbird's about:config from the options.\n\nSo to summarize the three approaches (this is not a proposed wording;\nI'm just trying to clear things up for myself):\n\n By default, Thunderbird will send HTML mail, wrap outgoing mail to 72\n characters for plain text mail, and transforms plain text mail to\n match the follow=flowed spec.\n\n To disable HTML mail, use Edit->Account Settings to uncheck the\n \"Compose messages in HTML format\" setting in the \"Composition &\n Addressing\" panel of the account to be used to send the patch.\n You've probably done this already --- many development lists do not\n like HTML mail for ordinary discussion, either.\n\n To disable wrapping and format=flowed, install the Toggle Word Wrap\n add-on that is available from\n https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/\n It adds a menu entry \"Enable Word Wrap\" that you can tick off. Now you\n can compose the message as you otherwise do (cut + paste,\n 'git format-patch' | 'git imap-send', etc), but you have to insert\n line breaks manually in any additional text that you type.\n\n That's it.\n\n If for some reason that add-on doesn't work (maybe you don't like\n add-ons?), use the Config Editor (under Edit->Preferences->Advanced)\n to set\n\n\tmailnews.send_plaintext_flowed => false\n\n to disable format=flowed and one of the following (?)\n\n\tmail.wrap_long_lines => false\n\tmailnews.wraplength => 0\n\n to disable line wrapping.\n\n You might also find the External Editor add-on from\n http://globs.org/articles.php?lng=en&pg=8 useful.\n There is a script in contrib/thunderbird-patch-inline which can be used\n as an external editor to include patches with Thunderbird and populate\n the \"To:\", \"Subject:\", and \"Cc:\" fields.\n"},{"id":"165930","messageId":"7vbp07clfd.fsf@alter.siamese.dyndns.org","threadId":"27088","inReplyTo":"1302898291.5926.9.camel@drew-northup.unet.maine.edu","subject":"Re: [PATCH 1/5] Documentation: describe the format of messages with inline patches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-15T20:24:38Z","receivedAt":"2011-04-15T20:24:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Drew Northup writes:\n\n> Maybe I'm too picky, but I'd feel more comfortable saying:\n>\n> ...\n> dashes, and then sent as a message which in our example stars with\n> \"arch/arm config files were...\" On the receiving end, readers can save\n> ...\n\nSurely you are ;-) I am tempted to squash the following into it.\n\nThanks.\n\n Documentation/git-format-patch.txt | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex c20e0ed..eebfa5c 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -255,9 +255,9 @@ Do the same for ia64 so we can have sleek & trim looking\n \n Typically it will be placed in a MUA's drafts folder, edited to add\n timely commentary that should not go in the changelog after the three\n-dashes, and then sent as a message whose body starts with \"arch/arm\n-config files were\". On the receiving end, readers can save\n-interesting patches in a UNIX mailbox and apply them with\n+dashes, and then sent as a message whose body, in our example, starts\n+with \"arch/arm config files were...\". On the receiving end, readers\n+can save interesting patches in a UNIX mailbox and apply them with\n linkgit:git-am[1].\n \n When a patch is part of an ongoing discussion, the patch generated by\n"},{"id":"166009","messageId":"201104171559.17683.barra_cuda@katamail.com","threadId":"27088","inReplyTo":"20110415023255.GE19829@elie","subject":"Re: [PATCH 4/5] Documentation: publicize KMail hints for sending patches inline","fromName":"Michele Ballabio","fromEmail":"barra_cuda@katamail.com","sentAt":"2011-04-17T13:57:21Z","receivedAt":"2011-04-17T13:57:21Z","isPatch":true,"sender":{"key":"barra_cuda@katamail.com","avatar":"https://avatars.githubusercontent.com/u/16371673?v=4"},"body":"On Friday 15 April 2011, Jonathan Nieder wrote:\n> I'm not sure what gotchas these hints are meant to work around.\n> They might be completely false.\n\nThese suggestion are there to warn and help about space/word wrap\nmangling, and to send a patch in the mail body (as per SubmittingPatches).\n\n> A quick search for \"how to send patches with KMail\" gave me the\n> \"external editor\" trick. Do these instructions work? ;-)\n\nThey do work, but maybe they are not so important, since they're\nhelpful only for the one-time-hack-patch and I-don't-want-to-setup-\ngit-send-email.\n\nWhen there are more than 3 or 4 patches to send, 'git send-email'\n(plus msmtp, if needed) is more comfortable.\n\nThere is however, an helpful hint in http://wiki.winehq.org/GitWine\n(never tried it, and I'd tend to prefer 'git send-email' anyway, don't\nknow if this should be mentioned in git docs):\n\n\n\tUsing local KMail folders, you can use the following approach:\n\ngit format-patch --stdout --keep-subject origin | formail -s procmail\n\n\tAssuming you don't already use procmail to sort your email, you can\n\tuse the following .procmailrc\n\n:0\n/home/username/.maildir/\n\n\tNow, all you need to do is to set up a new receiving account in\n\tKMail that collects mail from /home/username/.maildir and filter\n\temails coming in on that account to your drafts folder. \n"},{"id":"166027","messageId":"4DABDAB4.3000607@viscovery.net","threadId":"27088","inReplyTo":"7vtydzcse4.fsf@alter.siamese.dyndns.org","subject":"[PATCH 6/5 v2] Documentation/format-patch: suggest Toggle Word Wrap add-on for Thunderbird","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-04-18T06:31:16Z","receivedAt":"2011-04-18T06:31:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nOf the (now) three methods to send unmangled patches using Thunderbird,\nthis method is listed first because it provides a single-click on-demand\noption rather than a permanent change of configuration like the other\ntwo methods.\n\nSigned-off-by: Johannes Sixt \n---\nAm 4/15/2011 19:54, schrieb Junio C Hamano:\n> Care to reword \"superior\" in a less subjective way\n\nSure.\n\nDifferences to v1: More precise description where the new Option is found.\n\n-- Hannes\n\n Documentation/git-format-patch.txt | 18 ++++++++++++++----\n 1 files changed, 14 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt\nindex 8887375..a979b2a 100644\n--- a/Documentation/git-format-patch.txt\n+++ b/Documentation/git-format-patch.txt\n@@ -343,11 +343,21 @@ By default, Thunderbird will both wrap emails as well as flag\n them as being 'format=flowed', both of which will make the\n resulting email unusable by git.\n \n-There are two different approaches. One approach is to configure\n-Thunderbird to not mangle patches. The second approach is to use\n+There are three different approaches: use an add-on to turn off line wraps,\n+configure Thunderbird to not mangle patches, or use\n an external editor to keep Thunderbird from mangling the patches.\n \n-Approach #1 (configuration)\n+Approach #1 (add-on)\n+^^^^^^^^^^^^^^^^^^^^\n+\n+Install the Toggle Word Wrap add-on that is available from\n+https://addons.mozilla.org/thunderbird/addon/toggle-word-wrap/\n+It adds a menu entry \"Enable Word Wrap\" in the composer's \"Options\" menu\n+that you can tick off. Now you can compose the message as you otherwise do\n+(cut + paste, 'git format-patch' | 'git imap-send', etc), but you have to\n+insert line breaks manually in any text that you type.\n+\n+Approach #2 (configuration)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n Three steps:\n \n@@ -374,7 +384,7 @@ After that is done, you should be able to compose email as you\n otherwise would (cut + paste, 'git format-patch' | 'git imap-send', etc),\n and the patches will not be mangled.\n \n-Approach #2 (external editor)\n+Approach #3 (external editor)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n \n The following Thunderbird extensions are needed:\n-- \n1.7.5.rc1.1127.g94456\n"}]}