Re: branchs and tags and merges oh my!

diff --git a/18/c72fd215acb0f35ea3d91985d51c58ab54cbc9 b/18/c72fd215acb0f35ea3d91985d51c58ab54cbc9
new file mode 100644 (file)
index 0000000..adeae9d
--- /dev/null
+++ b/18/c72fd215acb0f35ea3d91985d51c58ab54cbc9
@@ -0,0 +1,84 @@
+Return-Path: <five9a2@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 2C0A8431FD0\r
+       for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 13:23:03 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.524\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.524 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1,\r
+       FREEMAIL_ENVFROM_END_DIGIT=2.223, FREEMAIL_FROM=0.001,\r
+       RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id 2lVh6yYIGua5 for <notmuch@notmuchmail.org>;\r
+       Sat,  2 Jul 2011 13:23:02 -0700 (PDT)\r
+Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com\r
+       [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id C0927431FB6\r
+       for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 13:23:02 -0700 (PDT)\r
+Received: by iwn37 with SMTP id 37so4019554iwn.26\r
+       for <notmuch@notmuchmail.org>; Sat, 02 Jul 2011 13:23:02 -0700 (PDT)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+       h=mime-version:sender:in-reply-to:references:date\r
+       :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
+       :content-transfer-encoding;\r
+       bh=NjxzyMYcnXiIvqoLjkTW9V/ceENBvAEyAO3umhmObsY=;\r
+       b=q+rKP+KlbdVR13tfW+b/aIHDv2SLNcRYj2nUQhJpnOmRGuhu2KwBd87ixG0kFGYrPd\r
+       P+qRWGE6Bf79K5m45Tu5RA5V+4T4qeCATOer91D+S1eDCoHD3zut+yzi1bnymY5z8YvG\r
+       tB9hs4Uf0HEswq+xGMV3hsfWeCBeyzx+8bWYE=\r
+MIME-Version: 1.0\r
+Received: by 10.231.44.65 with SMTP id z1mr4078030ibe.95.1309638182106; Sat,\r
+       02 Jul 2011 13:23:02 -0700 (PDT)\r
+Sender: five9a2@gmail.com\r
+Received: by 10.231.37.141 with HTTP; Sat, 2 Jul 2011 13:23:02 -0700 (PDT)\r
+In-Reply-To: <87r568yhq5.fsf@zancas.localnet>\r
+References: <87y60hn0mg.fsf@zancas.localnet> <87r568yhq5.fsf@zancas.localnet>\r
+Date: Sat, 2 Jul 2011 15:23:02 -0500\r
+X-Google-Sender-Auth: _apv0_7AmUa5a5DDUKin0ua4GZA\r
+Message-ID: <BANLkTik4hYYHpe_igt-Vf6t8e+_bVz6p+g@mail.gmail.com>\r
+Subject: Re: branchs and tags and merges oh my!\r
+From: Jed Brown <jed@59A2.org>\r
+To: David Bremner <david@tethera.net>\r
+Content-Type: text/plain; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 02 Jul 2011 20:23:03 -0000\r
+\r
+On Sat, Jul 2, 2011 at 07:44, David Bremner <david@tethera.net> wrote:\r
+>\r
+> A third strategy is "git checkout master && git merge -s ours 0.6".\r
+> Then history will look like this:\r
+>\r
+> =C2=A0freeze\r
+> --.-------------.----- master\r
+> =C2=A0 \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /\r
+> =C2=A0 =C2=A0-----------\r
+> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 release\r
+>\r
+> As long as every patch on the release branch is already on master, -s\r
+> ours (which throws away all the changes from the side branch) is\r
+> reasonable.\r
+\r
+Remind me of why bugfix patches can't (usually) be applied to the\r
+release branch first, then merged into master? When the patch is\r
+(accidentally or otherwise) applied to master first, then I think you\r
+have no choice but to have it appear twice in the history, once in\r
+master and once in release, and using the model you describe above\r
+seems the most sensible way to do that.\r