thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.18.2 2014-04-15T20:20:19Z 2014-04-15T20:20:19Z David Bremner david@tethera.net 2014-04-12T16:30:32Z urn:sha1:dd24fdd33a3c06b2c2ad6bcb8e7d18bc8442f51f If a git repository is non-bare, and core.worktree is not set, git tries to deduce the worktree. This deduction is not always helpful, e.g. % git --git-dir=$HOME/.nmbug clean -f would likely delete most of the files in the current directory 2014-04-08T10:39:28Z W. Trevor King wking@tremily.us 2014-03-10T00:28:49Z urn:sha1:c20016742681e1ed48c83de32639e10507ffa14d With two branches getting fetched (master and config), the branch referenced by FETCH_HEAD is ambiguous. For example, I have: $ cat FETCH_HEAD 41d7bfa7184cc93c9dac139d1674e9530799e3b0 \ not-for-merge branch 'config' of http://nmbug.tethera.net/git/nmbug-tags acd379ccb973c45713eee9db177efc530f921954 \ not-for-merge branch 'master' of http://nmbug.tethera.net/git/nmbug-tags (where I wrapped the line by hand). This means that FETCH_HEAD references the config branch: $ git rev-parse FETCH_HEAD 41d7bfa7184cc93c9dac139d1674e9530799e3b0 which breaks all of the FETCH_HEAD logic in nmbug (where FETCH_HEAD is assumed to point to the master branch). Instead of relying on FETCH_HEAD, use @{upstream} as the remote-tracking branch that should be merged/diffed/integrated into HEAD. @{upstream} was added in Git v1.7.0 (2010-02-12) [1], so relying on it should be fairly safe. One tricky bit is that bare repositories don't set upstream tracking branches by default: $ git clone --bare http://nmbug.tethera.net/git/nmbug-tags.git nmbug-bare $ cd nmbug-bare $ git remote show origin * remote origin Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git Push URL: http://nmbug.tethera.net/git/nmbug-tags.git HEAD branch: master Local refs configured for 'git push': config pushes to config (up to date) master pushes to master (up to date) While in a non-bare clone: $ git clone http://nmbug.tethera.net/git/nmbug-tags.git $ cd nmbug-tags $ git remote show origin * remote origin Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git Push URL: http://nmbug.tethera.net/git/nmbug-tags.git HEAD branch: master Remote branches: config tracked master tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) From the clone docs [2]: --bare:: Make a 'bare' Git repository… Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to `refs/remotes/origin/`. When this option is used, neither remote-tracking branches nor the related configuration variables are created. To use @{upstream}, we need to the local vs. remote-tracking distinction, so this commit adds 'nmbug clone', replacing the previously suggested --bare clone with a non-bare --no-checkout --separate-git-dir clone into a temporary work directory. After which: $ git rev-parse @{upstream} acd379ccb973c45713eee9db177efc530f921954 gives us the master-branch commit. Existing nmbug users will have to run the configuration tweaks and re-fetch by hand. If you don't have any local commits, you could also blow away your NMBGIT repository and re-clone from scratch: $ nmbug clone http://nmbug.tethera.net/git/nmbug-tags.git Besides removing the ambiguity of FETCH_HEAD, this commit allows users to configure which upstream branch they want nmbug to track via 'git config', in case they want to change their upstream repository. [1]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/1.7.0.txt [2]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/git-clone.txt 2014-04-08T10:32:34Z Tomi Ollila tomi.ollila@iki.fi 2014-04-05T09:47:29Z urn:sha1:5608e39a6bed25e32678b08d8f5f90bc42f451f8 Manual pages are now generated and during the generation the version string is read from `version` file, so this (currently failing) test checking manual page versions can be removed. While at it, changed the case pattern *[^0-9.]* to its portable alternative *[!0-9.]* 2014-04-08T10:30:42Z David Bremner david@tethera.net 2014-04-06T02:02:23Z urn:sha1:b6751cf8757409e5db2874ba14f2a07a11660b5b a first step towards actually instally the API docs 2014-03-23T11:33:34Z Jani Nikula jani@nikula.org 2014-03-13T12:04:05Z urn:sha1:87c2cd78fd8b3a83a6cfcc785df286ca458056dd Make nmbug-status more generally usable outside of nmbug by not hardcoding notmuch related things. This lets anyone publish html search views to mailing list messages with a custom config file, independent of nmbug. 2014-03-23T11:32:40Z Jani Nikula jani@nikula.org 2014-03-13T12:04:04Z urn:sha1:81a1aae2dc3b48c4e0dcc524455f32ca91087033 Prepare for more general use. 2014-03-11T22:51:22Z Jani Nikula jani@nikula.org 2014-02-08T13:36:54Z urn:sha1:6af2b05612b2bbd998804826c39276b77afce887 Add script to generate notmuch test databases using specified versions of notmuch. This is useful for generating material for database upgrade tests. This reuses the test infrastructure to have a sandbox environment for notmuch new etc. 2014-02-22T01:12:45Z Tomi Ollila tomi.ollila@iki.fi 2014-02-18T18:34:52Z urn:sha1:18d71908b2d2d5843d38ec94cf2daf5f1e8ecd29 Python dict() object does not have __values__() function which OrderedDict().values() (the stub provided in nmbug-status) could call to provide ordered list of values. By renaming this thinko to values() will make our stub work as expected -- dict items listed out in order those were added to the dictionary. 2014-02-15T01:45:07Z W. Trevor King wking@tremily.us 2014-02-14T16:48:55Z urn:sha1:320d4a856eca6f7d4363b3465e7032e658913ece David [1] and Tomi [2] both feel that the user's choice of LANG is not explicit enough to have such a strong effect on nmbug-status. For example, cron jobs usually default to LANG=C, and that is going to give you ASCII output: $ LANG=C python -c 'import locale; print(locale.getpreferredencoding())' ANSI_X3.4-1968 Trying to print Unicode author names (and other strings) in that encoding would crash nmbug-status with a UnicodeEncodeError. To avoid that, this patch hardcodes UTF-8, which can handle generic Unicode, and is the preferred encoding (regardless of LANG settings) for everyone who has chimed in on the list so far. I'd prefer trusting LANG, but in the absence of any users that prefer non-UTF-8 encodings I'm fine with this approach. While we could achieve the same effect on the output content by dropping the previous patch (nmbug-status: Encode output using the user's locale), Tomi also wanted UTF-8 hardcoded as the config-file encoding [2]. Keeping the output encoding patch and then adding this to hardcode both the config-file and output encodings at once seems the easiest route, now that fd29d3f (nmbug-status: Decode Popen output using the user's locale, 2014-02-10) has landed in master. [1]: id="877g8z4v4x.fsf@zancas.localnet" http://article.gmane.org/gmane.mail.notmuch.general/17202 [2]: id="m2vbwj79lu.fsf@guru.guru-group.fi" http://article.gmane.org/gmane.mail.notmuch.general/17209 2014-02-15T01:44:11Z W. Trevor King wking@tremily.us 2014-02-14T16:48:54Z urn:sha1:ffed8f2866a567d52eebeca02d3c362de07efc9d Instead of always writing UTF-8, allow the user to configure the output encoding using their locale. This is useful for previewing output in the terminal, for poor souls that don't use UTF-8 locales ;).