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 22:39:06 +0900 Message-ID: <877hrs67id.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> <873a2gkh0n.fsf@uwakimon.sk.tsukuba.ac.jp> <838wc8bxft.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1262957483 5839 80.91.229.12 (8 Jan 2010 13:31:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 13:31:23 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 08 14:31:16 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 1NTEvq-0002y4-9O for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 14:31:14 +0100 Original-Received: from localhost ([127.0.0.1]:37551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTEvq-0001Fo-R6 for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 08:31:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTEuh-0000Ej-Ln for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:30:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTEue-000099-0o for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:30:03 -0500 Original-Received: from [199.232.76.173] (port=36033 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTEud-00008c-Ha for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:29:59 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:33578) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NTEuY-0000dn-VR; Fri, 08 Jan 2010 08:29:55 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id B43A88218; Fri, 8 Jan 2010 22:29:49 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 696151A2C00; Fri, 8 Jan 2010 22:39:06 +0900 (JST) In-Reply-To: <838wc8bxft.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:119689 Archived-At: Eli Zaretskii writes: > > 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". >=20 > Terrific! So I just did a merge, but it is still considered > ``pending''? Who could have thought of a more confusing semantics?? > (Please don't take this as aimed at you, Stephen; I will shortly say > the same on the Bazaar list.) Please don't. Remember, the merge may have been interrupted due to a conflict, and it is not complete until it has been resolved. It's possible that better terminology could have been chosen, but it wasn't, and the bzr people are highly unlikely to change it now. > > > And how removing it resolves the problem at hand? > >=20 > > 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). >=20 > What is a microbranch? A word that I found in your post. ;-) Probably came from =D3scar. It's just a branch, which you have merged, but happens to have metadata you don't want committed and pushed to the main repository. The "micro" doesn't have much meaning (except maybe "these commits are too small in a semantic sense to be worth preserving in the official history"). > > 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. >=20 > So it's a way to pretend that a series of changes on a branch is a > single change that brings you to the last revision on that branch, is > that right? Yes, that's close enough. It "coalesces" one or more commits into a single commit. > If so, then I think it's not what I thought it would do. This > sub-thread started from ttn's comment that "Unrestrained publishing > of personal junk is bad manners." But ``personal junk'' can only > be in the commit messages, much less in the code. (It could, of > course, happen that I somehow commit a version with lots of debug > printouts or some such, but how is that ``personal junk''?) > "revert --forget-merges" forgets the whole commit, not just its > commit message, so it seems to throw out the baby with the > bathwater. It forgets the whole series of commits, but only in the current workspace. The original commits (metadata) are still present in the original workspace if you need them, I think. (It depends on the exact workflow, of course, but I think that's generally going to be the case.) Anyway, I thought that the point was that the commits were not "units of work", but accidental stopping points like "went to lunch". I think it makes sense to collect those accidental stopping points into the final commit, or perhaps into some intermediate commit. > Or am I missing something? No, I don't think so, except that you seem to be looking for a way to edit commit messages without changing the commit again, and for various reasons, some plausible and some inertia on the part of the developers, I don't think that's going to happen.