Re: [PATCH 4/4] emacs: Use the new JSON reply format.
[notmuch-archives.git] / 18 / c72fd215acb0f35ea3d91985d51c58ab54cbc9
1 Return-Path: <five9a2@gmail.com>\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 2C0A8431FD0\r
6         for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 13:23:03 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 1.524\r
10 X-Spam-Level: *\r
11 X-Spam-Status: No, score=1.524 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1,\r
13         FREEMAIL_ENVFROM_END_DIGIT=2.223, FREEMAIL_FROM=0.001,\r
14         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
15 Received: from olra.theworths.org ([127.0.0.1])\r
16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
17         with ESMTP id 2lVh6yYIGua5 for <notmuch@notmuchmail.org>;\r
18         Sat,  2 Jul 2011 13:23:02 -0700 (PDT)\r
19 Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com\r
20         [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
21         (No client certificate requested)\r
22         by olra.theworths.org (Postfix) with ESMTPS id C0927431FB6\r
23         for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 13:23:02 -0700 (PDT)\r
24 Received: by iwn37 with SMTP id 37so4019554iwn.26\r
25         for <notmuch@notmuchmail.org>; Sat, 02 Jul 2011 13:23:02 -0700 (PDT)\r
26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
27         h=mime-version:sender:in-reply-to:references:date\r
28         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
29         :content-transfer-encoding;\r
30         bh=NjxzyMYcnXiIvqoLjkTW9V/ceENBvAEyAO3umhmObsY=;\r
31         b=q+rKP+KlbdVR13tfW+b/aIHDv2SLNcRYj2nUQhJpnOmRGuhu2KwBd87ixG0kFGYrPd\r
32         P+qRWGE6Bf79K5m45Tu5RA5V+4T4qeCATOer91D+S1eDCoHD3zut+yzi1bnymY5z8YvG\r
33         tB9hs4Uf0HEswq+xGMV3hsfWeCBeyzx+8bWYE=\r
34 MIME-Version: 1.0\r
35 Received: by 10.231.44.65 with SMTP id z1mr4078030ibe.95.1309638182106; Sat,\r
36         02 Jul 2011 13:23:02 -0700 (PDT)\r
37 Sender: five9a2@gmail.com\r
38 Received: by 10.231.37.141 with HTTP; Sat, 2 Jul 2011 13:23:02 -0700 (PDT)\r
39 In-Reply-To: <87r568yhq5.fsf@zancas.localnet>\r
40 References: <87y60hn0mg.fsf@zancas.localnet> <87r568yhq5.fsf@zancas.localnet>\r
41 Date: Sat, 2 Jul 2011 15:23:02 -0500\r
42 X-Google-Sender-Auth: _apv0_7AmUa5a5DDUKin0ua4GZA\r
43 Message-ID: <BANLkTik4hYYHpe_igt-Vf6t8e+_bVz6p+g@mail.gmail.com>\r
44 Subject: Re: branchs and tags and merges oh my!\r
45 From: Jed Brown <jed@59A2.org>\r
46 To: David Bremner <david@tethera.net>\r
47 Content-Type: text/plain; charset=UTF-8\r
48 Content-Transfer-Encoding: quoted-printable\r
49 Cc: notmuch@notmuchmail.org\r
50 X-BeenThere: notmuch@notmuchmail.org\r
51 X-Mailman-Version: 2.1.13\r
52 Precedence: list\r
53 List-Id: "Use and development of the notmuch mail system."\r
54         <notmuch.notmuchmail.org>\r
55 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
56         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
57 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
58 List-Post: <mailto:notmuch@notmuchmail.org>\r
59 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
60 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
61         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
62 X-List-Received-Date: Sat, 02 Jul 2011 20:23:03 -0000\r
63 \r
64 On Sat, Jul 2, 2011 at 07:44, David Bremner <david@tethera.net> wrote:\r
65 >\r
66 > A third strategy is "git checkout master && git merge -s ours 0.6".\r
67 > Then history will look like this:\r
68 >\r
69 > =C2=A0freeze\r
70 > --.-------------.----- master\r
71 > =C2=A0 \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /\r
72 > =C2=A0 =C2=A0-----------\r
73 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 release\r
74 >\r
75 > As long as every patch on the release branch is already on master, -s\r
76 > ours (which throws away all the changes from the side branch) is\r
77 > reasonable.\r
78 \r
79 Remind me of why bugfix patches can't (usually) be applied to the\r
80 release branch first, then merged into master? When the patch is\r
81 (accidentally or otherwise) applied to master first, then I think you\r
82 have no choice but to have it appear twice in the history, once in\r
83 master and once in release, and using the model you describe above\r
84 seems the most sensible way to do that.\r