From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Confusing "bzr log" as result of merges Date: Sat, 21 May 2011 19:09:35 +0200 Message-ID: <8762p42d68.fsf@wanadoo.es> References: <83ipt4fqyy.fsf@gnu.org> <87ei3s2fdm.fsf@wanadoo.es> <83tycodmog.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305997797 11601 80.91.229.12 (21 May 2011 17:09:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 May 2011 17:09:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 21 19:09:54 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QNpgX-00034Q-Gx for ged-emacs-devel@m.gmane.org; Sat, 21 May 2011 19:09:53 +0200 Original-Received: from localhost ([::1]:59152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNpgW-00076f-Gb for ged-emacs-devel@m.gmane.org; Sat, 21 May 2011 13:09:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNpgT-00074w-2C for emacs-devel@gnu.org; Sat, 21 May 2011 13:09:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNpgS-0004Or-29 for emacs-devel@gnu.org; Sat, 21 May 2011 13:09:49 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:34450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNpgR-0004O6-NG for emacs-devel@gnu.org; Sat, 21 May 2011 13:09:48 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QNpgQ-00032D-Nr for emacs-devel@gnu.org; Sat, 21 May 2011 19:09:46 +0200 Original-Received: from 31.red-79-148-47.dynamicip.rima-tde.net ([79.148.47.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2011 19:09:46 +0200 Original-Received: from ofv by 31.red-79-148-47.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 May 2011 19:09:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 31.red-79-148-47.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:fYY7N9vWI0fW6wcoRAOLAwuCJp0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139603 Archived-At: Eli Zaretskii writes: >> Create a branch emacs-common and commit there all the changes intended >> for emacs-23 and trunk. > > Given that the trunk and the branch diverge quite quickly, I don't > think what you suggest is practical. The divergence is in the basic > infrastructure, such as access to global variables and members of > buffer and keyboard objects. That makes such a common branch > problematic, as it is not clear which one of the diverging branches it > should follow, and how to be sure that all 3 branches "work". emacs-common does not need to "work" (nor even compile!) It is just a temporary storage for submitted revisions, with the net result of producing a cleaner history, reducing housekeeping and diminishing the frequency of errors ("bzr merge" is less error-prone than an humane figuring out which revisions need to be cherry-picked.) >> From time to time *merge* (not cherry-pick!) emacs-common into >> emacs-23 and trunk. > > We merge already, but then reverse cherry-pick those revisions that > are not intended for the trunk, before committing. At least this is > my understanding of how merges from the branch work. I thought that you do both: cherry-picking from emacs-23 into trunk and merging emacs-23 into trunk. But even if that's is not so, reverting (reversing, as you say) the commits that does not belong into trunk creates a messy history. This is undesirable. >> Long time ago I advised against mixing cherry-picks and merges and >> suggested this strategy, but was discarded because it is too >> complex. I'm sure that as time passes and you get bitten again and again >> by the current practice it will finally look extremely simple. > > Since no one is even bothered by these issues, I very much doubt that > anything will be done any time soon. I thought that the existence of this thread demonstrates that someone is bothered by these issues.