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: log format for vc-bzr Date: Sat, 09 Jan 2010 00:05:51 +0100 Message-ID: <873a2gb3jk.fsf@telefonica.net> References: <200912081747.nB8HlwPR021836@godzilla.ics.uci.edu> <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> <873a2gkh0n.fsf@uwakimon.sk.tsukuba.ac.jp> <838wc8bxft.fsf@gnu.org> <874omwd7wx.fsf@telefonica.net> <83ocl4a60j.fsf@gnu.org> <87ocl4bie4.fsf@telefonica.net> <83ljg89ypj.fsf@gnu.org> <87bph4b9z4.fsf@telefonica.net> <83d41k9tgc.fsf@gnu.org> <877hrsb704.fsf@telefonica.net> <83aawo9qws.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1262992304 30516 80.91.229.12 (8 Jan 2010 23:11:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 23:11:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 09 00:11:35 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 1NTNzS-0005AK-KN for ged-emacs-devel@m.gmane.org; Sat, 09 Jan 2010 00:11:34 +0100 Original-Received: from localhost ([127.0.0.1]:44881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTNzT-0003Kx-5M for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 18:11:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTNub-0007Za-BV for emacs-devel@gnu.org; Fri, 08 Jan 2010 18:06:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTNuU-0007TI-Im for emacs-devel@gnu.org; Fri, 08 Jan 2010 18:06:30 -0500 Original-Received: from [199.232.76.173] (port=36851 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTNuT-0007Se-Kj for emacs-devel@gnu.org; Fri, 08 Jan 2010 18:06:25 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:51360) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NTNuS-0003CR-T5 for emacs-devel@gnu.org; Fri, 08 Jan 2010 18:06:25 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NTNuM-0003Ao-Qc for emacs-devel@gnu.org; Sat, 09 Jan 2010 00:06:18 +0100 Original-Received: from 180.red-83-36-171.dynamicip.rima-tde.net ([83.36.171.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2010 00:06:18 +0100 Original-Received: from ofv by 180.red-83-36-171.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jan 2010 00:06:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 180.red-83-36-171.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:NXmL5LaA+8UXB28ds0Osn4cN7Cw= 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:119742 Archived-At: Eli Zaretskii writes: >> From: Óscar_Fuentes >> Date: Fri, 08 Jan 2010 22:51:07 +0100 >> >> Eli Zaretskii writes: >> >> >> > That's your mistake, right there: this is user documentation, not >> >> > documentation of bzr internals. >> >> >> >> Merge point is not about internal details. It is a fundamental concept >> >> which the user is required to know if he pretends to make an effective >> >> use of the DVCS. >> > >> > If it's such an important fundamental point, then why it is not >> > mentioned even once in the docs? At least I couldn't find it. >> >> IMHO, Bazaar docs are way too simplistic when explaining DVCS core >> concepts, if they explain them at all. > > I wasn't looking for explanation of core dVCS concepts. Sorry, I thought that you asked why the bzr docs do not explain what a merge point is. > I was looking for the explanation of what "revert --forget-merges" > does. It could have been explained without introducing the "merge > point" concept. I don't think so. > But even if we accept that "merge points" must be understood for the > explanation of --forget-merges, the manual still shouldn't have used > "pending merges". If a tool has a "merge" command, then a "merge" is > what that command does. So talking about "pending merges" after a > merge was already done is simply bad didactically. And the "merges" > part in --forget-merges is likewise a bad idea. --forget-merge-points > might be a better one, because everyone will understand that a "merge > point" is not the same as "merge". A "merge" is the abbreviated term for "merge point". It is a merge of two branches. At the time you use --forget-merges the merge point still doesn't exist. It is created by the commit. So the hypothetical name for the option would be more like --commit-the-source-changes-but-do-not-create-a-merge-point -- Óscar