thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=release 2017-08-18T22:42:35Z 2017-08-18T22:42:35Z Vladimir Panteleev notmuch@thecybershadow.net 2017-08-17T00:41:10Z urn:sha1:ca4688e103c644fa383108a79668e8e0b4dbe262 A leading / in paths in a .gitignore file matches the beginning of the path, meaning that for patterns without slashes, git will match files only in the current directory as opposed to in any subdirectory. Prefix relevant paths with / in .gitignore files, to prevent accidentally ignoring files in subdirectories and possibly slightly improve the performance of "git status". 2012-12-25T12:49:24Z David Bremner bremner@debian.org 2012-12-16T12:33:17Z urn:sha1:098ef4af4d0a52a6b4daed5324a7c77f6c9108da The idea is run some code under valgrind --leak-check=full and report a summary, leaving the user to peruse the log file if they want. We go to some lengths to preserve the log files from accidental overwriting; the full corpus takes about 3 hours to run under valgrind on my machine. The naming of the log directories may be slightly controversial; in the unlikely event of two runs in less than a second, the log will be overwritten. A previous version with mktemp+timestamp was dismissed as overkill; just mktemp alone does not sort nicely. One new test is included, to check notmuch new for memory leaks. 2012-12-15T12:17:58Z David Bremner bremner@debian.org 2012-12-03T12:48:53Z urn:sha1:ceaf5ca6c02e494eee5b9b9aa955459b3cd29471 The caching and uncaching seem to be necessarily manual, as timing the initial notmuch new is one of our goals with this suite. 2012-12-15T12:17:57Z David Bremner bremner@debian.org 2012-12-03T12:13:31Z urn:sha1:74a883562b3e4593c75fa7625ff5cabab46a6466 Unpacking is not really the expensive step (compared to the initial notmuch new), but this is a pre-requisite to caching the database. 2012-11-26T12:39:21Z David Bremner bremner@debian.org 2012-11-17T16:28:15Z urn:sha1:7beeb8c88a014ecbc53d8241f10683b3c4c16228 This is not near as fancy as as the unit tests, on the theory that the code should typically be crashing when performance tuning. Nonetheless, there is plenty of room for improvement. Several more of the pieces of the test infrastructure (e.g. the option parsing) could be factored out into test/test-lib-common.sh