unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Mark Walters <markwalters1009@gmail.com>
To: Carl Worth <cworth@cworth.org>, David Bremner <david@tethera.net>,
	notmuch <notmuch@notmuchmail.org>
Subject: Re: [RFC PATCH] Re: excessive thread fusing
Date: Mon, 21 Apr 2014 08:20:13 +0100	[thread overview]
Message-ID: <8738h7kv2q.fsf@qmul.ac.uk> (raw)
In-Reply-To: <877g6kmcmh.fsf@qmul.ac.uk>


>> I haven't tracked through all the logic of the existing algorithm for
>> this case. But I don't like hearing that notmuch constructs different
>> threads for the same messages presented in different orders. This sounds
>> like a bug separate from what we've discussed above. 

I think I have now found this bug and it is separate from the malformed
In-Reply-To problems.

The problem is that when we merge threads we update all the thread-ids
of documents in the loser thread. But we don't (if I understand the code
correctly) update dangling "metadata" references to threads which don't
(yet) have any documents.

To make this explicit consider the 2 messages 17,18 in the set. 

Message 17 has id <87wrkidfrh.fsf@pinto.chemeng.ucl.ac.uk> and has no
references/in-reply-to so has no parents.

Message 18 has a reference to <87wrkidfrh.fsf@pinto.chemeng.ucl.ac.uk>
and an in-reply-to to <e.fraga@ucl.ac.uk> and
<87wrkidfrh.fsf@pinto.chemeng.ucl.ac.uk>

If you add 17 first then it gets thread-id 1 and then when you add 18 message 18 gets
thread-id 2 as does the dangling link to the "unseen" message
e.fraga@ucl.ac.uk, and then message 17 is moved to thread-id 2.

However, if you add 18 first then it gets thread-id 1 and the dangling
link gets id 1. When 17 is added it gets thread-id 2, message 18 gets
thread-id updated to 2 *but* the dangling link to e.fraga@ucl.ac.uk does
not get updated so stays thread-id 1.

In particular when 52 comes along with its link to e.fraga@ucl.ac.uk
then:

        In the first case it gets put in thread-id 3 and the other two
        messages get moved into thread 3.

        In the second case, message 52 gets put in thread 3 and thread 1
        (the dangling link) gets moved into thread 3 leaving thread 2
        (containing messages 17 and 18) untouched.

Best wishes

Mark

  reply	other threads:[~2014-04-21  7:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 12:33 excessive thread fusing David Bremner
2014-04-19 17:52 ` Eric
2014-04-19 21:04   ` Andrei POPESCU
2014-04-20 16:48     ` Austin Clements
2014-04-20 17:46       ` Austin Clements
2014-04-20  7:14 ` [RFC PATCH] " Mark Walters
     [not found]   ` <87oazwjq1e.fsf@yoom.home.cworth.org>
2014-04-20 12:03     ` Mark Walters
2014-04-21  7:20       ` Mark Walters [this message]
2014-04-21 16:20         ` Austin Clements
2022-01-01  0:26         ` David Bremner
2014-04-20 12:59     ` David Bremner

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: https://notmuchmail.org/

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

  git send-email \
    --in-reply-to=8738h7kv2q.fsf@qmul.ac.uk \
    --to=markwalters1009@gmail.com \
    --cc=cworth@cworth.org \
    --cc=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    /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://yhetil.org/notmuch.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).