git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonio Ospite <ospite@studenti.unina.it>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Stephen Boyd <bebarino@gmail.com>,
	Markus Heidelberg <markus.heidelberg@web.de>,
	Nanako Shiraishi <nanako3@lavabit.com>
Subject: Re: [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches
Date: Wed, 20 Oct 2010 00:45:33 +0200	[thread overview]
Message-ID: <20101020004533.b64d446c.ospite@studenti.unina.it> (raw)
In-Reply-To: <7v4oci11k6.fsf@alter.siamese.dyndns.org>

[-- Attachment #1: Type: text/plain, Size: 5128 bytes --]

On Tue, 19 Oct 2010 11:26:33 -0700
Junio C Hamano <gitster@pobox.com> wrote:

Thanks for commenting Junio.

> Antonio Ospite <ospite@studenti.unina.it> writes:
> 
> > Make second and subsequent patches appear as replies to the first patch,
> > even when an initial In-Reply-To is supplied; this is the typical
> > behaviour we want when we send a series with cover letter in reply to
> > some discussion, and this is also what the man page says about
> > the --in-reply-to option.
> 
> I am not so sure if that is what the documentation says.
>

Sorry, I meant the man page part about --[no-]chain-reply-to, I mistyped
that and generated more confusion than was "necessary".

>  1. When --in-reply-to gives $reply_to, the first one becomes a reply to
>     that message, with or without --chain-reply-to.
>

No doubts on that.

>  2. When --chain-reply-to is in effect, all the messages are strung
>     together to form a single chain.  The first message may be in reply to
>     the $reply_to given by --in-reply-to command line option (see
>     previous), or the root of the discussion thread.  The second one is a
>     response to the first one, and the third one is a response to the
>     second one, etc.
>

This is pretty clear as well.

>  3. When --chain-reply-to is not in effect:
>
>     a. When --in-reply-to is used, too, the second and the subsequent ones
>        become replies to $reply_to.  Together with the first rule, all
>        messages become replies to $reply_to given by --in-reply-to.
> 
>     b. When --in-reply-to is not used, presumably the second and
>        subsequent ones become replies to the first one, which would be the
>        root.
> 
> The documentation is reasonably clear about the 1., 2. and 3a. above, I
> think, even though I do not think 3b. is clearly specified.
>

In general, 3b. is specified in --[no-]chain-reply-to section, the
"problem" with 3a. is that --in-reply-to _overrides_ the behavior
specified by --no-chain-reply-to.

So I think that the whole issue really boils down to the question:
Should --in-reply-to apply _only_ to the first email?
The doc for the corresponding git-format-patch option gives _one_
answer, and you know that :)

By answering to this question with a YES also in git-send-email, we are
making --in-reply-to *independent* from --[no-]chain-reply-to, hence
the very simple test.

> If you are changing 3a. above so that the first message becomes a response
> to $reply_to, and the second one becomes a response to the first message
> (and the third and subsequent ones too when --chain-reply-to is not in
> effect), you would need to update the documentation as well.  Even if it
> might be of good kind, it would be a change of the established behaviour.
>

Right, the documentation needs be updated as well, thanks for pointing
this out. I think I am going to copy from the git-format-patch man
page.
So, do you agree to this change of behavior as long as it is documented?

> > diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> > index a298eb0..410b85f 100755
> > --- a/t/t9001-send-email.sh
> > +++ b/t/t9001-send-email.sh
> > @@ -295,6 +295,20 @@ test_expect_success $PREREQ 'Valid In-Reply-To when prompting' '
> >  	! grep "^In-Reply-To: < *>" msgtxt1
> >  '
> >  
> > +test_expect_success $PREREQ 'In-Reply-To in second patch with --thread' '
> > +	clean_fake_sendmail &&
> > +	git send-email \
> > +		--from="Example <nobody@example.com>" \
> > +		--to=nobody@example.com \
> > +		--thread \
> > +		--in-reply-to="<unique-message-id@example.com>" \
> > +		--smtp-server="$(pwd)/fake.sendmail" \
> > +		$patches $patches \
> > +		2>errors
> 
> You are breaking the && chain here.
>

Some other tests do that as well, the last line is a command by
itself not and-chained with the git-send-email invocation. I guess the
logic behind this is that the test succeeds if the _last_ command
succeeds. If this is wrong then some other tests are affected too.

> > +        # The second patch should be seen as reply to the first one
> > +        test $(sed -n -e "s/^In-Reply-To:\(.*\)/\1/p" msgtxt2) = $(sed -n -e "s/^Message-Id:\(.*\)/\1/p" msgtxt1)
> > +'
> 
> You would need to test the interaction with --chain-reply-to as well, so
> there should be another test, and you would probably need three messages
> fed to send-email not just two to see the effect of the interaction.
> 

I saw the tests in the other mail, but under my interpretation
we should just ensure --in-reply-to is applying to the first
message only (so we check the second one), if so from the third one on
--[no-]chain-reply-to is totally unrelated to --in-reply-to.

I think I can make the test more explicit tho, like:
("In-Reply-To" of second message) != $initial_reply_to

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2010-10-19 22:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-14  9:38 [PATCH] git-send-email.perl: fix In-Reply-To for second and subsequent patches Antonio Ospite
2010-10-14 18:22 ` Jonathan Nieder
2010-10-15  7:56   ` Antonio Ospite
2010-10-19  9:52     ` [PATCH v2] " Antonio Ospite
2010-10-19 18:26       ` Junio C Hamano
2010-10-19 18:45         ` Junio C Hamano
2010-10-19 22:45         ` Antonio Ospite [this message]
2010-10-26 13:50           ` Antonio Ospite
2010-11-05 20:59           ` [PATCH v3] git-send-email.perl: make initial In-Reply-To apply only to first email Antonio Ospite
2010-11-05 22:36             ` Matthieu Moy
2010-11-09 21:23               ` Junio C Hamano
2010-11-10 11:45                 ` Antonio Ospite
2010-11-10 19:48                   ` Junio C Hamano
2010-11-12 14:55                     ` [PATCHi v4] " Antonio Ospite
2010-11-12 20:53                       ` Junio C Hamano
2010-11-12 21:44                       ` Junio C Hamano
2010-11-12 22:51                         ` Antonio Ospite
2010-11-05 21:41           ` [PATCH v2] git-send-email.perl: fix In-Reply-To for second and subsequent patches Jonathan Nieder
2010-11-08 11:03             ` Antonio Ospite

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

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

  git send-email \
    --in-reply-to=20101020004533.b64d446c.ospite@studenti.unina.it \
    --to=ospite@studenti.unina.it \
    --cc=bebarino@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=markus.heidelberg@web.de \
    --cc=nanako3@lavabit.com \
    /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.
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 NNTP newsgroup(s).