git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Rüdiger Sonderfeld" <ruediger@c-plusplus.de>,
	git@vger.kernel.org, davidk@lysator.liu.se,
	"Sergei Organov" <osv@javad.com>,
	"Kevin Ryde" <user42@zip.com.au>,
	"Michele Ballabio" <barra_cuda@katamail.com>
Subject: Re: Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.)
Date: Fri, 13 Jan 2012 16:59:49 -0800	[thread overview]
Message-ID: <7vlipbxfne.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120113233158.GD7343@burratino> (Jonathan Nieder's message of "Fri, 13 Jan 2012 17:31:58 -0600")

Jonathan Nieder <jrnieder@gmail.com> writes:

> The hints at [1] might also be useful, in case you would like to try
> and consider improving the manpage to document them if they work.

Don't you need similar updates to sections for other MUAs and procedures?

I suspect that the reason why you added the new text there is because you
know KMail users are very lazy bunch, and once they see a "KMail"
subsection, they will skip everything outside the subsection. Thunderbird
users would also be lazy---after choosing one of the three approaches
presented, they will skip anything outside the subsubsection. So I can
understand that we would need something in these individual subsections,
but the advice does not logically belong there.

Perhaps rephrasing the early part of the Discussion section, with an
illustration that is designed to be more visible, would be a better
approach?

For example, we could take your log message and stuff it there:

    The opening "From " line and following lines in "git format-patch" are
    for your mailer and should be omitted except for fields that differ from
    the mail header when reading your patch into an email body. For example,
    the output of your format-patch may begin like this:

          From 13c41b41b832d41680ccd33a2422ef8217965566 Mon Sep 17 00:00:00 2001
          From: Jonathan Nieder <jrnieder@gmail.com>
          Date: Fri, 13 Jan 2012 17:22:41 -0600
          Subject: Documentation/format-patch: mention removal of in-body headers

          The opening "From " line and following lines in ...

    The part you should send in the body of your e-mail message begins at the
    first blank line. The "From $SHA1 $magic_timestamp" line and other header
    lines are there to make it look like a mbox, and if you send it in e-mail,
    they will become redundant.

    You can leave "From:" and/or "Subject:" lines in, if they are
    different from the e-mail you will be sending out (e.g. you are
    forwarding a patch written by somebody else, as a follow up to an
    ongoing discussion and do not want the subject of your e-mail message
    to help threading).  E.g. your message _may_ begin like this:

          From: Jonathan Nieder <jrnieder@gmail.com>
          Subject: Documentation/format-patch: mention removal of in-body headers

          The opening "From " line and following lines in ...

    when you are not Jonathan, and you are sending it as a response to
    an existing discussion thread.

Or something like that?

  reply	other threads:[~2012-01-14  0:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12 15:44 [PATCH] git-blame.el: Fix compilation warnings Rüdiger Sonderfeld
2012-01-12 16:26 ` Jonathan Nieder
2012-01-12 17:08   ` Rüdiger Sonderfeld
2012-01-13 23:31     ` Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.) Jonathan Nieder
2012-01-14  0:59       ` Junio C Hamano [this message]
2012-01-14 18:31         ` Sending patches with KMail Jonathan Nieder
2012-01-14 18:34           ` Jonathan Nieder
2012-01-15  2:14           ` Junio C Hamano
2012-01-14 19:18         ` Sending patches with KMail (Re: [PATCH] git-blame.el: Fix compilation warnings.) Rüdiger Sonderfeld
2012-06-10  7:38 ` [PATCH] git-blame.el: use mapc instead of mapcar Jonathan Nieder
2012-06-10 11:58   ` [PATCH 1/3] git-blame.el: Do not use goto-line in lisp code Lawrence Mitchell
2012-06-10 11:58     ` [PATCH 2/3] git-blame.el: Use with-current-buffer where appropriate Lawrence Mitchell
2012-06-10 11:58       ` [PATCH 3/3] git-blame.el: Do not use bare 0 to mean (point-min) Lawrence Mitchell
2012-06-14  5:08     ` [PATCH 1/3] git-blame.el: Do not use goto-line in lisp code Jonathan Nieder
2012-06-14  9:14       ` Lawrence Mitchell
2012-06-14  9:37         ` [PATCH v2 " Lawrence Mitchell
2012-06-14  9:37           ` [PATCH v2 2/3] git-blame.el: Use with-current-buffer where appropriate Lawrence Mitchell
2012-06-14  9:38             ` [PATCH v2 3/3] git-blame.el: Do not use bare 0 to mean (point-min) Lawrence Mitchell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vlipbxfne.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barra_cuda@katamail.com \
    --cc=davidk@lysator.liu.se \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=osv@javad.com \
    --cc=ruediger@c-plusplus.de \
    --cc=user42@zip.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).