From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: log format for vc-bzr Date: Wed, 09 Dec 2009 09:41:13 -0500 Message-ID: References: <200912081747.nB8HlwPR021836@godzilla.ics.uci.edu> <874oo1w9y1.fsf@telefonica.net> <87tyw1uss6.fsf@telefonica.net> <200912082203.nB8M3FLP023771@godzilla.ics.uci.edu> <87hbs1at4u.fsf@notengoamigos.org> <87fx7ksc8t.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1260369692 22097 80.91.229.12 (9 Dec 2009 14:41:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 14:41:32 +0000 (UTC) Cc: Fuentes , emacs-devel@gnu.org, Dan Nicolaescu , =?iso-8859-1?Q?=D3scar?=, Andreas Schwab , Jason Earl To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 09 15:41:24 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 1NINjH-0006N0-AU for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 15:41:23 +0100 Original-Received: from localhost ([127.0.0.1]:35171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NINjH-0004wr-2S for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 09:41:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NINjD-0004we-86 for emacs-devel@gnu.org; Wed, 09 Dec 2009 09:41:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NINj8-0004ub-NR for emacs-devel@gnu.org; Wed, 09 Dec 2009 09:41:18 -0500 Original-Received: from [199.232.76.173] (port=38806 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NINj8-0004uW-Jx for emacs-devel@gnu.org; Wed, 09 Dec 2009 09:41:14 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:51852 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NINj8-0000IL-8o for emacs-devel@gnu.org; Wed, 09 Dec 2009 09:41:14 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEAFNFH0vO+INN/2dsb2JhbACBTNYKhCwEihs X-IronPort-AV: E=Sophos;i="4.47,368,1257138000"; d="scan'208";a="51096424" Original-Received: from 206-248-131-77.dsl.teksavvy.com (HELO pastel.home) ([206.248.131.77]) by ironport2-out.pppoe.ca with ESMTP; 09 Dec 2009 09:41:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 594C08065; Wed, 9 Dec 2009 09:41:13 -0500 (EST) In-Reply-To: <87fx7ksc8t.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Wed, 09 Dec 2009 18:55:14 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:118455 Archived-At: >> There is nothing wrong with that, but do that only in your private >> local branch and don't publish those junk commits. > That's easy to say, but frequent rebasing is not a desirable option in > bzr. If the junk commits bother the community, then you should make > it an explicit policy that people simply should not make junk commits > in any branch that might eventually be pushed to the mainline. FWIW, I've been using two different VCS for the past many years: one for my own local Emacs branch (was Arch and is now Bzr), and the other (CVS) for the upstream. That means I can't just push my changes upstream, instead I have to copy patches "manually". A friend recently asked me how I was "pushing" my changes and whether switching to Bzr was done so that UI could do such "push" more easily, and after thinking about it, I came to the conclusion that it probably wouldn't change that much to my workflow: most of my local patches are developped in a piecemeal fashion with lots of silly commits in inconsistent states and many of them have been written years ago and then regularly merged with upstream changes, so the history is really messy. Furthermore, this "copy the patch by hand" is usually not as simple as it seems: very often I end up rewriting the whole change from scratch, because in retrospect I see that it would be cleaner to do it some other way. I.e. the "commit" is an occasion for me to revisit my change, clean it up, etc... So I completely agree: such tiny changes are great for your proviate branch, but you have to clean then up before you install them on the trunk. If you end up rebasing too often, it means your change is old and it deserves taking a second look (e.g. to make sure it was kept uptodate with other changes), so don't rebase too often: instead just merge and know that when will come the time to install the change, you'll have to recreate a clean history by hand. The good thing about it is that the history you create doesn't have to reflect the true history: it can be much cleaner, simpler, more linear. You can create it specifically so that it is easy to understand. This is in constrast to the real history of that changem which will often involve trying a few different implementation strategies, Stefan