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: Fri, 08 Jan 2010 14:48:30 +0100 Message-ID: <874omwd7wx.fsf@telefonica.net> 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=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1262958569 9477 80.91.229.12 (8 Jan 2010 13:49:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2010 13:49:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 08 14:49:22 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 1NTFDK-0006Kz-M9 for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 14:49:19 +0100 Original-Received: from localhost ([127.0.0.1]:43385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTFDK-0004ZQ-RS for ged-emacs-devel@m.gmane.org; Fri, 08 Jan 2010 08:49:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NTFDF-0004Y8-7S for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:49:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NTFDA-0004Wv-Nb for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:49:12 -0500 Original-Received: from [199.232.76.173] (port=59481 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NTFDA-0004Ws-I3 for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:49:08 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:44317) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NTFD9-0000m7-RE for emacs-devel@gnu.org; Fri, 08 Jan 2010 08:49:08 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NTFCy-0006Bi-74 for emacs-devel@gnu.org; Fri, 08 Jan 2010 14:48:56 +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 ; Fri, 08 Jan 2010 14:48:56 +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 ; Fri, 08 Jan 2010 14:48:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 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:HY3NMOg8wnnsKo7gW0fwK38eLQo= 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:119693 Archived-At: Eli Zaretskii writes: >> > --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". > > Terrific! So I just did a merge, but it is still considered > ``pending''? Who could have thought of a more confusing semantics?? bzr always requires to commit after a merge. That's why the merge is "pending". Other tools, like git, does an implicit commit unless there are conflicts. >> > 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). > > What is a microbranch? I begun to use that term for short-lived branches where you usually implement small features that requires just a few commits. For bzr it is a branch as any other but, in practice, you may be interested on giving a special treatment to it. We expect that branches that implement large changes (like multy-tty, etc) shall be merged retaining history. For a microbranch, that history may have little relevance and maybe it is better to not incorporate it into upstream. >> 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. > > 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? Right. > 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. > > Or am I missing something? --forget-merges forgets the revisions that lead to the final result, but not the final result. You need to enter a commit message anyways. As for the "personal junk", each one has its own opinion, as always. I think that some revisions (or even the full series of revisions that ended on something useful) can be considered junk (because they are half-assed experiments, backups, etc). However, I think too that that way of working allows people to left aside worries about "take care of not breaking things" or "here I'll wish to save the current status of the work, but then I'll have to think about a sensible commit message for it". This is a matter of policy. If the agreement is that only "high quality" revisions are allowed to be merged into upstream, --forget-merges may be useful for some people. [snip] -- Óscar