From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: reversion revulsion [was: log format for vc-bzr] Date: Fri, 08 Jan 2010 11:09:33 +0100 Message-ID: <87wrzszz4y.fsf_-_@ambire.localdomain> 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> <871vj3sxgy.fsf@telefonica.net> <87ws0vrd46.fsf@telefonica.net> <87hbqxa9ti.fsf@ambire.localdomain> <87k4vtd1uy.fsf@telefonica.net> <83ljg9as4g.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262945574 32602 80.91.229.12 (8 Jan 2010 10:12:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 10:12:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 08 11:12:47 2010 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 1NTBpm-0005Fo-Us for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 11:12:47 +0100 Original-Received: from localhost ([127.0.0.1]:33796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTBpm-0004mV-KX for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 05:12:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTBpd-0004ja-9y for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:12:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTBpa-0004fO-Ee for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:12:36 -0500 Original-Received: from [199.232.76.173] (port=36137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTBpa-0004f4-4T for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:12:34 -0500 Original-Received: from smtp-out13.alice.it ([85.33.2.18]:1542) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTBpZ-00068x-OE for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:12:33 -0500 Original-Received: from FBCMMO05.fbc.local ([192.168.184.136]) by smtp-out13.alice.it with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:12:27 +0100 Original-Received: from FBCMCL01B05.fbc.local ([192.168.69.86]) by FBCMMO05.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:11:59 +0100 Original-Received: from ambire.localdomain ([79.16.71.163]) by FBCMCL01B05.fbc.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 11:11:59 +0100 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1NTBmf-0005cA-4r for emacs-devel@gnu.org; Fri, 08 Jan 2010 11:09:33 +0100 In-Reply-To: <83ljg9as4g.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Jan 2010 11:00:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-OriginalArrivalTime: 08 Jan 2010 10:11:59.0251 (UTC) FILETIME=[03B34E30:01CA904B] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ 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:119663 Archived-At: () Eli Zaretskii () Fri, 08 Jan 2010 11:00:15 +0200 As usual, the Bazaar documentation doesn't say anything about this option that can be grokked by Bazaar non-experts. --forget-merges Remove pending merge marker, without changing any files. What is a ``pending merge marker''? And how removing it resolves the problem at hand? And if this is the magic wand to leave personal commit comments out of the public repository, then shouldn't we add this to the recommended workflow on the wiki? I'm concerned that mis- (or any, actually) use of "bzr revert" in trunk/ (as opposed to in quickfixes/) will do some damage upstream, in the sense that any change that discards (shared) history is an ugly mistake. That's just from a correctness pov. I dread the performance implications of having to do (and possibly screwing up): cd .../trunk # 0 bzr update # 1 bzr merge ../quickfixes # 2 bzr commit # 3 bzr revert --forget-merges # 4 IIUC step 3 publishes, as does step 4, defeating atomicity. Really, i would be much happier to see "bzr revert" prohibited entirely on or wherever such policy lives, and see local branch history suppression effected in step 2 in the merge proper. That is where i want to express "merge quickfixes/ changes, allowing manual editing of a new comment (log entry) seeded with the log entries of the quickfixes/ changes, but in the end *discarding* those log entries". More succinctly: Can bzr do what "git merge --squash" does? thi