Re: [notmuch] [PATCH] Store thread ids for messages that we haven't seen yet

2010-04-14 Thread Carl Worth
On Tue, 13 Apr 2010 16:36:30 +0100, James Westby 
 Your choice. I prefer putting them in the same commit to be more
 self-documenting, and then using the capabilities of my VCS to verify
 the change if i desire.

But that's my point. With it split, I can actually use git checkout to
go to a state where the test exists, but the bug hasn't been fixed. With
it combined, there's no such state. (I can checkout state with the bug,
but then there's nothing in the test suite to exercise it.)

 This would fix up threads for all existing messages?

Yes. It seems un-right for notmuch to provide a feature on an arbitrary
subset of messages, (those that happened to be added after the user
switched to some particular version of notmuch).

 Probably a good thing to have, but not that important to me. In my
 case I can always open the bug in my browser if I want to see the full

I agree it's not totally essential. But it should be easy enough to pick
up in the upcoming database upgrade, (which may actually end up being a
full rebuild anyway---I've got a lot of things to change and a full
rebuild might be the fastest thing to do).


Description: PGP signature
notmuch mailing list

Re: [notmuch] [PATCH] Store thread ids for messages that we haven't seen yet

2010-04-13 Thread Carl Worth
On Sat, 13 Mar 2010 16:27:57 -0500, James Westby 
 This allows us to thread messages even when we receive them out of
 order, or never receive the root.

Thanks for this patch, James! It's especially nice to have the fix come
in with additions to the test suite as well.

I did split up the commit so the addition to the test suite happens
first. That way it's easy to test the test itself, (verifying that it
fails before the fix, and then passes after the fix).

I also added a few documentation and other cleanups as follow-on
commits. Hopefully, they don't change the logic at all, but make things
easier to understand.

So that's all pushed.

Then, I started implementing support for retroactively storing
thread_ids for non-existing messages references in already-existing
messages. It took me perhaps too long that a change like that, (while
useful), is too invasive for the current 0.2 release, and not essential
for this particular feature.

So I've postponed that part at least. I hope to make a database-schema
upgrade a key part of a release in a couple of cycles, (for this
feature and for list: and folder:).


Description: PGP signature
notmuch mailing list