From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: log format for vc-bzr Date: Fri, 08 Jan 2010 19:50:00 +0900 Message-ID: <873a2gkh0n.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1262947322 5844 80.91.229.12 (8 Jan 2010 10:42:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 10:42:02 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 08 11:41:55 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 1NTCHt-0001IS-Tt for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 11:41:50 +0100 Original-Received: from localhost ([127.0.0.1]:53257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTCHu-0002H8-DJ for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 05:41:50 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTCH4-0001of-0p for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:40:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTCGz-0001lw-3x for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:40:57 -0500 Original-Received: from [199.232.76.173] (port=58248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTCGy-0001lp-T2 for emacs-devel@gnu.org; Fri, 08 Jan 2010 05:40:52 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:40378) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTCGu-00073E-Gk; Fri, 08 Jan 2010 05:40:48 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 94B391535A8; Fri, 8 Jan 2010 19:40:43 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 44F531A2C00; Fri, 8 Jan 2010 19:50:01 +0900 (JST) In-Reply-To: <83ljg9as4g.fsf@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:119666 Archived-At: Eli Zaretskii writes: > > bzr revert --forget-merges > > > > allows to commit into microbranches as one pleases and leave a nice > > corpse afterwards. > > 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''? A "pending merge" is a merge that you have started with "bzr merge" (or perhaps a "bzr pull" that resulted in a conflict) but not yet finished with "bzr commit". The "pending merge marker" is an internal variable that (1) acts as a flag that there is a merge pending, so you will be warned if you try to do something that would mess up the merge, and (2) records the additional parent to record in the commit. > And how removing it resolves the problem at hand? By removing the pointer to the parents in the microbranch along with the merge marker, the history (metadata) recorded in the microbranch becomes inaccessible (in Lisp terms, garbage). The "real" history (files changed by the merge operation) is not touched, and so the content changes, but not the historical metadata, is recorded in the upcoming commit. > 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? It's a wiki ....