notmuch/test/T670-duplicate-mid.sh, branch feature/git-remotethread-based email index, search, and tagginghttps://git.notmuchmail.org/git/notmuch/atom?h=feature%2Fgit-remote2021-05-22T12:08:02Zlib/n_d_index_file: re-use thread-id of existing message2021-05-22T12:08:02ZDavid Bremnerdavid@tethera.net2021-05-15T18:40:22Zurn:sha1:3f4de98e7c8c70f9a86a4f899147126f79907bd9
This prevents the message document getting multiple thread-id terms
when there are multiple files with the same message-id.
This change shifts some thread ids, requiring adjustments to other tests.
test: add known broken test for duplicate thread-id terms2021-05-22T12:02:58ZDavid Bremnerdavid@tethera.net2021-05-15T13:05:07Zurn:sha1:349fc2980346db2dba619cda5d9cdf0d943d3053
According to my bijection, this bug has been present since commit
411675a6ce in 2017. It is not completely clear what harm it causes in
regulary use, but it (at least) makes notmuch crash when compiled with
-DDEBUG_DATABASE_SANITY.
build: drop support for xapian versions less than 1.42020-04-24T00:28:45ZTomi Ollilatomi.ollila@iki.fi2020-04-21T21:07:29Zurn:sha1:00cdfe10717020423870fdaf56e973db9aba9f5a
Xapian 1.4 is over 3 years old now (1.4.0 released 2016-06-24),
and 1.2 has been deprecated in Notmuch version 0.27 (2018-06-13).
Xapian 1.4 supports compaction, field processors and retry locking;
conditionals checking compaction and field processors were removed
but user may want to disable retry locking at configure time so it
is kept.
cli/show: emit new whole-message crypto status output2019-05-26T11:20:23ZDaniel Kahn Gillmordkg@fifthhorseman.net2019-05-25T18:04:06Zurn:sha1:4cb789aa090fb6ba3c7897584ecbcc0a547b2f81
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.
Sensibly structured encrypted and/or signed messages will work fine
with this. The only requirement for the simplest encryption + signing
is that the message have all of its encryption and signing protection
(the "cryptographic envelope") in a contiguous set of MIME layers at
the very outside of the message itself.
This is because messages with some subparts signed or encrypted, but
with other subparts with no cryptographic protection is very difficult
to reason about, and even harder for the user to make sense of or work
with.
For further characterization of the Cryptographic Envelope and some of
the usability tradeoffs, see here:
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
test: make regexp test conditional on field processors2018-09-14T11:54:20ZDavid Bremnerdavid@tethera.net2018-09-10T01:36:17Zurn:sha1:c846e15ffee526b70a28b512710968b2db77b724
Normally we'd mark it broken, but perversely missing regexp support
actually makes the test pass.
test: add known broken test for regexp search of second subject2018-05-03T10:44:49ZDavid Bremnerdavid@tethera.net2017-12-14T14:32:34Zurn:sha1:4ac23c5978ff963c18a012b6b230b26f9ef98c43
We expect this to give the same answer as the non-regexp subject
search. It does not because the regexp search relies on the value
slot, which currently contains only one subject.
test: use $(dirname "$0") for sourcing test-lib.sh2017-10-20T22:52:49ZJani Nikulajani@nikula.org2017-09-25T20:38:19Zurn:sha1:a863de1e43ee34f6f5794a2759fdceb287e851aa
Don't assume the tests are always run from within the source tree.
test/duplicate-mid: check for subject with notmuch-show2017-09-06T00:53:06ZDavid Bremnerdavid@tethera.net2017-08-27T23:58:23Zurn:sha1:64e30aeb245631e3e30091e426fd45bfc2dcb448
In [1] Mark showed that the the current code (d7a49e81) is not
consistent in it's handling of subjects of messages with duplicate
message-ids (or in notmuch-speak, of messages with multiple files).
notmuch-search uses indexing order and explicitedly preserves the
first. notmuch-show (apparently) uses alphabetical (or at least xapian
term order) of filenames. In a perfect world we would probably report
all subjects in the json output; at the very least we should be
consistent.
[1]: id:87378dny3d.fsf@qmul.ac.uk
lib: enforce that n_message_reindex takes headers from first file2017-09-06T00:51:57ZDavid Bremnerdavid@tethera.net2017-08-27T23:58:22Zurn:sha1:debfae20db9a45ce7e12ac51db2b0104cd3b0be2
This is still a bit stopgap to be only choosing one set of headers,
but this seems like a more defensible set of headers to choose.
test: known broken test for subject after reindexing2017-09-06T00:51:21ZDavid Bremnerdavid@tethera.net2017-08-27T23:58:21Zurn:sha1:36a3d65034f1aa8de77c21013c63f0198aef386c
In [1], Mark gave a test that was behaving strangly. This turns out to
be specific to reindexing. I suppose one could argue that picking the
lexicographically last file name is a defensible choice, but it's
almost as easy to take the first, which seems more intuitive. So mark
the current situation as broken.
[1]: id:1503859703-2973-1-git-send-email-markwalters1009@gmail.com