Re: branchs and tags and merges oh my!

diff --git a/28/7e2344746fe98d257b2c86c7622bc91fd57ca6 b/28/7e2344746fe98d257b2c86c7622bc91fd57ca6
new file mode 100644 (file)
index 0000000..8c11d30
--- /dev/null
+++ b/28/7e2344746fe98d257b2c86c7622bc91fd57ca6
@@ -0,0 +1,104 @@
+Return-Path: <bremner@unb.ca>\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 2132B41ED98\r
+       for <notmuch@notmuchmail.org>; Fri,  1 Jul 2011 17:51:18 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.29\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 MEX2VjgUJzBP for <notmuch@notmuchmail.org>;\r
+       Fri,  1 Jul 2011 17:51:16 -0700 (PDT)\r
+Received: from tempo.its.unb.ca (tempo.its.unb.ca [131.202.1.21])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 6279F41ED9B\r
+       for <notmuch@notmuchmail.org>; Fri,  1 Jul 2011 17:51:16 -0700 (PDT)\r
+Received: from zancas.localnet\r
+       (fctnnbsc30w-142167176081.pppoe-dynamic.High-Speed.nb.bellaliant.net\r
+       [142.167.176.81]) (authenticated bits=0)\r
+       by tempo.its.unb.ca (8.13.8/8.13.8) with ESMTP id p61NlFNf014219\r
+       (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);\r
+       Fri, 1 Jul 2011 20:47:16 -0300\r
+Received: from bremner by zancas.localnet with local (Exim 4.76)\r
+       (envelope-from <bremner@unb.ca>)\r
+       id 1QcnQY-0005zw-Px; Fri, 01 Jul 2011 20:47:14 -0300\r
+From: David Bremner <david@tethera.net>\r
+To: Keith Packard <keithp@keithp.com>, notmuch@notmuchmail.org\r
+Subject: Re: branchs and tags and merges oh my!\r
+In-Reply-To: <yun7h81brkn.fsf@aiko.keithp.com>\r
+References: <87y60hn0mg.fsf@zancas.localnet> <yun7h81brkn.fsf@aiko.keithp.com>\r
+User-Agent: Notmuch/0.6 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Fri, 01 Jul 2011 20:47:04 -0300\r
+Message-ID: <87tyb5mumf.fsf@zancas.localnet>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\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 00:51:18 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard <keithp@keithp.com> wrote:\r
+> > 2) merge master onto the release branch\r
+>=20\r
+> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging.\r
+\r
+Can you elaborate? Naively it seems like one ends up with the same kind\r
+of spur of history off of the 0.6 tag in both cases.\r
+\r
+=2D---.--------------master\r
+    \\r
+     ---- 0.6 ---- bugfix\r
+\r
+versus\r
+\r
+=2D----.----------.\r
+      \          \=20\r
+       ---- 0.6--------master\r
+             \\r
+              ----- bugfix\r
+\r
+> As an alternative, you probably should have simply put non-release\r
+> patches on a separate 'feature branch' (probably residing in the feature\r
+> author's repository) which would then be merged onto master post-0.6\r
+\r
+Yes, that is certainly nice from a git history point of view. On the\r
+other hand the point of separating the roles of feature merger from\r
+release mechanic was to allow Carl more time to work on merging features\r
+into master, and I'm not sure how turning master over to the release\r
+manager helps that.\r
+\r
+David\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.11 (GNU/Linux)\r
+\r
+iJwEAQECAAYFAk4OXHgACgkQTiiN/0Um85lbKQQAg2BbIQ4pJ8n14zV4fVUG6dOE\r
+UgxlFFCddhdWEbizz4ROCl6uhS/FQ4ytBp73k++btS3P5DExVke8qJ2RCcaNmB98\r
+nzfk/YACsRiPnm+86CzjL9tF0U1Bgl7L0hXdce4rXqJpXu6SDXEWlFuK5vjCAFBc\r
+Nh2HEiRH04jigJgSAUI=\r
+=vbBP\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r