Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first

Josh Triplett [off-list ref] writes:

Add message_id and ref_message_id fields to struct rev_info, used in show_log
with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
Use these in git-format-patch to make the second and subsequent patch mails
replies to the first patch mail.

Signed-off-by: Josh Triplett <redacted>
---
Resend of previous patch as part of new patch series.

While I understand what you said about imap-send, I really would
feel better if this was optional.  Do not change the default
output format, please.

On Mon, 2006-07-10 at 14:44 -0700, Junio C Hamano wrote:

Josh Triplett [off-list ref] writes:

quoted

Add message_id and ref_message_id fields to struct rev_info, used in show_log
with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
Use these in git-format-patch to make the second and subsequent patch mails
replies to the first patch mail.

Signed-off-by: Josh Triplett <redacted>
---
Resend of previous patch as part of new patch series.

While I understand what you said about imap-send, I really would
feel better if this was optional.  Do not change the default
output format, please.

So rather than the --no-thread option provided in the second patch of
this series, you'd prefer a --thread option to enable setting the
In-Reply-To/References headers?

Note that I based the direction of the --no-thread switch on
git-send-email's inclusion of these headers by default with no way to
turn them off, figuring that having an option to do so gave it an
advantage over git-send-email while remaining consistent with it.  I
also figured that most people would not mess with the defaults, and thus
the default should make a patch series more readable on mailing lists.

- Josh Triplett

Josh Triplett [off-list ref] writes:

quoted

While I understand what you said about imap-send, I really would
feel better if this was optional.  Do not change the default
output format, please.

So rather than the --no-thread option provided in the second patch of
this series, you'd prefer a --thread option to enable setting the
In-Reply-To/References headers?

Eh, that's not what I meant.

I do not mind the code you added to log-tree.c and revision.h,
and honestly I do not care which of threading or non-threading
mode is the default, although I think your explanation that it
parallels what send-email does makes a lot of sense.

But I do mind that the code added by the first patch to
cmd_format_patch runs by default, and worse yet, there is no
option turn it off.  Setting message_id and ref_message_id in
rev_info struct should be something the end user should ask for
explicitly by invoking the command with an option, perhaps
--with-message-id, which you probably would also want to turn on
when any of --no-thread, --thread or --initial-reply-to options
are given.
-

On Fri, 2006-07-14 at 11:23 -0700, Junio C Hamano wrote:

Josh Triplett [off-list ref] writes:

quoted

quoted

While I understand what you said about imap-send, I really would
feel better if this was optional.  Do not change the default
output format, please.

So rather than the --no-thread option provided in the second patch of
this series, you'd prefer a --thread option to enable setting the
In-Reply-To/References headers?

Eh, that's not what I meant.

I do not mind the code you added to log-tree.c and revision.h,
and honestly I do not care which of threading or non-threading
mode is the default, although I think your explanation that it
parallels what send-email does makes a lot of sense.

But I do mind that the code added by the first patch to
cmd_format_patch runs by default, and worse yet, there is no
option turn it off.  Setting message_id and ref_message_id in
rev_info struct should be something the end user should ask for
explicitly by invoking the command with an option, perhaps
--with-message-id, which you probably would also want to turn on
when any of --no-thread, --thread or --initial-reply-to options
are given.

How would that work though?  Threading requires a Message-Id on at least
the first message, so to avoid Message-IDs by default would require
turning off threading by default; I can do that if you like, but you
suggested that you didn't mind having threading as the default.  I
could, however, avoid generating Message-Id on the subsequent messages,
and avoid generating that Message-Id if you give --no-thread.  Would
that work?

- Josh Triplett