From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: log format for vc-bzr Date: Sat, 09 Jan 2010 00:24:03 +0200 Message-ID: <83aawo9qws.fsf@gnu.org> References: <200912081747.nB8HlwPR021836@godzilla.ics.uci.edu> <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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1262989447 21678 80.91.229.12 (8 Jan 2010 22:24:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 22:24:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 08 23:24:00 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 1NTNFP-0004WY-Ar for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 23:23:59 +0100 Original-Received: from localhost ([127.0.0.1]:40866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTNFP-0003L5-Lm for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 17:23:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTNFJ-0003JW-Ti for emacs-devel@gnu.org; Fri, 08 Jan 2010 17:23:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTNFF-0003Ae-F9 for emacs-devel@gnu.org; Fri, 08 Jan 2010 17:23:53 -0500 Original-Received: from [199.232.76.173] (port=37812 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTNFF-0003AW-6l for emacs-devel@gnu.org; Fri, 08 Jan 2010 17:23:49 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:63269) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTNFE-0004Mp-NS for emacs-devel@gnu.org; Fri, 08 Jan 2010 17:23:49 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0KVY006008B65R00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 09 Jan 2010 00:23:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.222.44]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KVY003088VMD9Q0@a-mtaout23.012.net.il>; Sat, 09 Jan 2010 00:23:47 +0200 (IST) In-reply-to: <877hrsb704.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:119739 Archived-At: > From: =C3=93scar_Fuentes > Date: Fri, 08 Jan 2010 22:51:07 +0100 >=20 > Eli Zaretskii writes: >=20 > >> > That's your mistake, right there: this is user documentation, = not > >> > documentation of bzr internals. > >>=20 > >> Merge point is not about internal details. It is a fundamental c= oncept > >> which the user is required to know if he pretends to make an eff= ective > >> 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. >=20 > 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. I was lookin= g for the explanation of what "revert --forget-merges" does. It could have been explained without introducing the "merge point" concept. 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-point= s might be a better one, because everyone will understand that a "merge point" is not the same as "merge".