GNU bug report logs - #15361
git send-email creates one report per patch

Previous Next

To reply to this bug, email your comments to 15361 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: git send-email creates one report per patch
Date: Thu, 12 Sep 2013 16:11:34 -0400

Package: debbugs.gnu.org

If you send a collection of patches to bug-foo via git send-email,
it creates one report per patch. Here's why:

How it normally works:

You send a new report to the bug-foo mailing list.
You get an ack saying "thanks, reply to 123 <at> debbugs with more info".
When the mail arrives at the bug-foo mailing list after processing,
it has "Bug#123" in the subject, and seems to be addressed "To: 123 <at> debbugs".

If someone sends a reply, it either has "Re: Bug#123" in the subject, or
it goes to 123 <at> debbugs. In either case, it is trivial for debbugs to
work out that the message is a reply to an existing bug rather than a
new report.

The lovely emails sent by git have no consistent subject and are all
addressed to bug-foo. Thus, there is no way to tell they are all
related except by tracking the message-id of the original report and
looking for a references: header in later emails.

I did actually implement that, but it replies on the message-id getting
into the bug database index, which is only updated every 5(?) minutes or
so. When a bunch of emails arrive all at the same time, as from git, it
cannot work.

To fix this, need to force message-id into the index immediately after a
new report arrives. I don't know how much work that is, or when I'll
have time to look at it.

Workaround: first create a report ("here's the problem for which I will
send a patch"), then send patches to that bug number rather than bug-foo.

Message #8 received at 15361 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15361 <at> debbugs.gnu.org
Subject: Re: bug#15361: git send-email creates one report per patch
Date: Mon, 23 Sep 2013 07:42:35 -0700

On Thu, Sep 12, 2013 at 1:11 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> Package: debbugs.gnu.org
>
> If you send a collection of patches to bug-foo via git send-email,
> it creates one report per patch. Here's why:
...

Hi Glenn,
Doesn't git send-email's --in-reply-to option solve this problem?

       --in-reply-to=<identifier>
           Make the first mail (or all the mails with --no-thread) appear as a
           reply to the given Message-Id, which avoids breaking threads to
           provide a new patch series. The second and subsequent emails will
           be sent as replies according to the --[no]-chain-reply-to setting.

           So for example when --thread and --no-chain-reply-to are specified,
           the second and subsequent patches will be replies to the first one
           like in the illustration below where [PATCH v2 0/3] is in reply to
           [PATCH 0/2]:

               [PATCH 0/2] Here is what I did...
                 [PATCH 1/2] Clean up and tests
                 [PATCH 2/2] Implementation
                 [PATCH v2 0/3] Here is a reroll
                   [PATCH v2 1/3] Clean up
                   [PATCH v2 2/3] New tests
                   [PATCH v2 3/3] Implementation

Message #11 received at 15361 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 15361 <at> debbugs.gnu.org
Subject: Re: bug#15361: git send-email creates one report per patch
Date: Mon, 02 Jun 2014 13:49:14 -0400

> I did actually implement that, but it replies on the message-id getting
> into the bug database index, which is only updated every 5(?) minutes or
> so. When a bunch of emails arrive all at the same time, as from git, it
> cannot work.
> To fix this, need to force message-id into the index immediately after a
> new report arrives. I don't know how much work that is, or when I'll
> have time to look at it.

Doing it more promptly won't be always sufficient: the message may
arrive in a different order.  So in order to make it work reliably, we
should do something more devious, such as:
- postpone processing of messages with an "in-repy-to" that's not found
  in the message-id database.
- when we receive a message with an "in-reply-to" that's not found in
  the message-id database, allocate a new bug-nb for it and add that
  message-id to the database.  Then when a message arrives, don't only
  look for its in-reply-to in the database but also its message-id!
  And then figure out a way to handle the "deeper" threading case where
  we first receive the grand-child, then the grand parent, and only
  third the in-between.
Postponing, seems like a "cheap" way to solve 99% of the problem.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.