notmuch.el: controlling what does and doesn't get expanded in searches
[notmuch-archives.git] / 75 / 93f86ee5a53d57feec26348c568703ddb31e45
1 Return-Path: <pieter@praet.org>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id 1B613429E35\r
6         for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 00:55:57 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id OA3U0MDoQ7tk for <notmuch@notmuchmail.org>;\r
16         Sat, 14 Jan 2012 00:55:52 -0800 (PST)\r
17 Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
18  [74.125.82.45])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
19  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
20  7F2E3431FB6    for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 00:55:52 -0800\r
21  (PST)\r
22 Received: by wgbds11 with SMTP id ds11so3527227wgb.2\r
23         for <notmuch@notmuchmail.org>; Sat, 14 Jan 2012 00:55:51 -0800 (PST)\r
24 Received: by 10.180.99.232 with SMTP id et8mr2038545wib.8.1326531351220;\r
25         Sat, 14 Jan 2012 00:55:51 -0800 (PST)\r
26 Received: from localhost ([109.131.75.86])\r
27         by mx.google.com with ESMTPS id f36sm14123023wbo.10.2012.01.14.00.55.50\r
28         (version=TLSv1/SSLv3 cipher=OTHER);\r
29         Sat, 14 Jan 2012 00:55:50 -0800 (PST)\r
30 From: Pieter Praet <pieter@praet.org>\r
31 To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
32 Subject: Re: revised patch for gmime init, with test.\r
33 In-Reply-To: <874nw0nfa8.fsf@zancas.localnet>\r
34 References: <1325306261-21444-2-git-send-email-kaz.rag@gmail.com>\r
35         <1325388169-8444-1-git-send-email-david@tethera.net>\r
36         <871ur4ltnx.fsf@praet.org> <877h0wnu1l.fsf@zancas.localnet>\r
37         <874nw0nfa8.fsf@zancas.localnet>\r
38 User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1\r
39         (x86_64-unknown-linux-gnu)\r
40 Date: Sat, 14 Jan 2012 09:54:04 +0100\r
41 Message-ID: <8762ger7f7.fsf@praet.org>\r
42 MIME-Version: 1.0\r
43 Content-Type: text/plain; charset=us-ascii\r
44 X-BeenThere: notmuch@notmuchmail.org\r
45 X-Mailman-Version: 2.1.13\r
46 Precedence: list\r
47 List-Id: "Use and development of the notmuch mail system."\r
48         <notmuch.notmuchmail.org>\r
49 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
50         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
51 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
52 List-Post: <mailto:notmuch@notmuchmail.org>\r
53 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
54 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
55         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
56 X-List-Received-Date: Sat, 14 Jan 2012 08:55:57 -0000\r
57 \r
58 On Fri, 13 Jan 2012 05:05:35 -0400, David Bremner <david@tethera.net> wrote:\r
59 > On Thu, 12 Jan 2012 23:46:46 -0400, David Bremner <david@tethera.net> wrote:\r
60 > > On Thu, 12 Jan 2012 18:25:38 +0100, Pieter Praet <pieter@praet.org> wrote:\r
61 > > > On Sat, 31 Dec 2011 23:22:46 -0400, David Bremner <david@tethera.net> wrote:\r
62 > > \r
63 > > > with differing hashes), this has the potential of causing confusion\r
64 > > > and/or quite some extra work when debugging using git-bisect(1), so\r
65 > > > I'd like to propose that bugfixes for (to-be-)released code are only\r
66 > > > applied on the 'maint' branch ('release' in the case of Notmuch),\r
67 > > > and then immediately merged back into 'master'.  In fact, this would\r
68 > > > preferrably happen after *every* (series of) commit(s) on the 'maint'\r
69 > > > branch, to prevent issues like [1].\r
70 > > \r
71 > > There is some merit it to this. On the other hand, it makes the history\r
72 > > messier.  [1] would have also been prevented by making the patch against\r
73 > > the right branch.\r
74\r
75 > I thought about this a bit more, and I agree that at least the release\r
76 > candidates (basically anything tagged on branch release) ought to be\r
77 > merged back to master. Since any series of bugfix patches seems to be\r
78 > cause for a new release candidate, this should avoid the need to have\r
79 > doubly applied patches.\r
80\r
81 \r
82 Thanks!\r
83 \r
84 > I'm less convinced about the need to merge every little doc change and\r
85 > debian packaging change back to master right away. This might be a\r
86 > purely aesthetic objection; [...]\r
87 \r
88 See my previous reply [1].\r
89 \r
90 > [...] I'm not sure if the extra merge commits\r
91 > cause any problems for e.g. bisection.\r
92\r
93 \r
94 Infrequent merging increases the possibility of bugs due to unforeseen\r
95 interactions between commits on different branches, which is likely to\r
96 require one to do a multitude of fake merges (`git merge --no-commit')\r
97 in order to properly track down the offending commit, so... frequent\r
98 merging would actually *prevent* issues when bisecting.\r
99 \r
100 \r
101 > d\r
102 \r
103 \r
104 Peace\r
105 \r
106 -- \r
107 Pieter\r
108 \r
109 [1] id:"878vlar7ka.fsf@praet.org"\r