From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Marten Veldthuis <marten@veldthuis.com>, Notmuch Mail
	<notmuch@notmuchmail.org>
In-Reply-To: <87zl3nr3vc.fsf@marten.rgoc.rug.nl>
References: <878wb7wsnt.fsf@servo.finestructure.net>
	<87zl3nr3vc.fsf@marten.rgoc.rug.nl>
Date: Fri, 05 Feb 2010 12:49:21 -0500
Message-ID: <871vgzwp26.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Subject: Re: [notmuch] loss of duplicate messages
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 05 Feb 2010 18:25:59 +0100, Marten Veldthuis <marten@veldthuis.com>=
 wrote:
> This is indeed the correct behaviour of notmuch. There has been some
> discussion on it in the past, I believe with proposals to track both
> messages and show only one; but I don't think I've seen proponents of
> showing both duplicate messages.
>=20
> Personally I'd find it rather annoying if I'd see messages twice. But I
> do see the value in being sure that your mail gets delivered through the
> list. I believe the solution I've seen discussed was for notmuch to
> somehow determine which of the duplicates holds the most information
> (which would be the one through the list, not the one directly to you).

Hey, Marten.  Thanks for the reply.

The problem I have with only returning one of the redundant messages is
that I don't think anyone could ever really convince me that notmuch has
the ability to decide which of the redundant messages is the *right* one
to return.  I think notmuch is currently just returning the first one it
indexes, but why is that better than returning the one most recently
indexed?

A policy of only returning one is going to be problematic for folks who
want or expect to see the other.  And in fact think I want to see both.
I have both, and I've asked notmuch to index both, so why shouldn't it
return both in a search?

jamie.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJLbFoiAAoJEO00zqvie6q8cNgP/jE2Saj7zDn8MbGSQmVryCfh
J2kGCGmhYFTCEuzlt8QvbKFT27i4Z2Fre5Apz4M0NwcGimMqYyQ3W3YDMsqUCfqA
4kHVZLjH+/Ee7t9Z5NGGqoRkt9nSWjCT7qeM2A4/vVgQrbkU4qN6y6MXCc+hX24o
Uyx+WORNC06W9dnU8Pnhrz9gBKPaI3BCY5zhtdyqr77tuWaQazoAfspZ3wJRkJub
O6eZYZdKFc+whsSOFfzCX9KeQ7+G1tYP2bjjL5DYhiJR7cYPXN8dfHOawY/2zyzz
GF32eT229v+bB+4auMEXI7nIO9eJ6us6KglNXQghwUi9JUX3aFXxEyqwOVankCHU
9MyZ+npLh6o3IaLBTi4fL73JPMYO+FxbJoHq4u42M0yk/2isCT/ejOKZ1b8+E6S/
o2CIatckE1NDzFM4rWnrFmfBIp3GbSbOEjo8t690D/glGq2OdRcyA0j6W8h+gmB5
jw0I+AB9t+rX/x6Th1QOOHyQSWuw0jePrysaon2pS4fjW0Q7SbqIXHxVSmq+mi6F
GX89alCQxmpL8RE9NGjA5T+FKr+7Nl9ZTJ9xwH74b5utR78tSPpENPhLiwnaTb+Q
OwViyKy+DfnZvOxGg2w0ng7RHJGCEsgyKI5TX5PumapImAxqhKZ6dDdeVQdHPCHk
nUpKptAx+76gy3cQMNds
=dd/C
-----END PGP SIGNATURE-----
--=-=-=--