From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs is on Bazaar now. Date: Mon, 28 Dec 2009 16:27:37 -0500 Message-ID: <87637qhjqu.fsf@red-bean.com> References: <87d4206n80.fsf@canonical.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262035682 12921 80.91.229.12 (28 Dec 2009 21:28:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Dec 2009 21:28:02 +0000 (UTC) Cc: Andreas Schwab , Kenichi Handa To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 28 22:27:56 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NPN84-0004Rp-N9 for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2009 22:27:53 +0100 Original-Received: from localhost ([127.0.0.1]:52137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPN85-0000D5-3l for ged-emacs-devel@m.gmane.org; Mon, 28 Dec 2009 16:27:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPN80-0000Cq-4L for emacs-devel@gnu.org; Mon, 28 Dec 2009 16:27:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPN7u-0000CO-OD for emacs-devel@gnu.org; Mon, 28 Dec 2009 16:27:46 -0500 Original-Received: from [199.232.76.173] (port=59244 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPN7u-0000CL-Hs for emacs-devel@gnu.org; Mon, 28 Dec 2009 16:27:42 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:48795) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NPN7u-00078F-Bn for emacs-devel@gnu.org; Mon, 28 Dec 2009 16:27:42 -0500 Original-Received: from localhost ([127.0.0.1]:37683 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.71) (envelope-from ) id 1NPN7q-0001tB-G3; Mon, 28 Dec 2009 15:27:38 -0600 In-Reply-To: (Andreas Schwab's message of "Mon, 28 Dec 2009 20:59:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118886 Archived-At: Andreas Schwab writes: > Kenichi Handa writes: >>>>> > I followed that page and created "quickfixex" branch. >>>>> It doesn't make sense to create a branch for every little commit. >>> > No, I'm not going to do that. I'll use that branch for >>> > "One-Off Change" repeatedly. >>> That's just the same. >> ??? What is the same with what? > Making a branch for every little commit. What we have here is a failure to communicate :-). Currently, BzrForEmacsDevs recommends keeping a 'trunk' branch (used for merging from other branches and for committing to upstream, but never used for development) and a 'quickfixes' branch (for quick little fixes, where you don't want to have to create a whole new branch each time). The document recommends that 'quickfixes' be treated like any other non-trunk local branch: you keep it up-to-date, you commit changes there, and when ready, you merge it into trunk and then commit in trunk. The only thing special about it is that it persists basically forever -- unlike feature branches, which you usually remove when done. So by using 'quickfixes', Kenichi is following the recommended procedure. A separate question is, is this a *good* procedure for quick fixes? Kenichi has a point: for a simple typo fix, it's annoying to have to commit it in quickfixes, and then go merge it into trunk and commit it again (with its own log message beginning with "Merge: "). It would be easier to just make the change in trunk and commit from there. However, I wasn't sure what complications might arise from doing that ('trunk' is a bound branch), so we recommended a very conservative, very safe procedure. We can certainly tweak the instructions, if they don't work well for certain situations! I just want to make sure we don't recommend any methods that make it too easy to mess up history or shoot oneself in the foot, that's all. Does anyone know a better workflow for quick fixes? -Karl