From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: Help me unstick my bzr, please. Date: Sun, 17 Jan 2010 09:50:42 +0200 Message-ID: <87d419tbjh.fsf@kobe.laptop> References: <20100115222724.GB1931@muc.de> <87r5pqkc63.fsf@kobe.laptop> <20100116213821.GB6676@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263714690 414 80.91.229.12 (17 Jan 2010 07:51:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2010 07:51:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 17 08:51: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 1NWPus-00081o-8c for ged-emacs-devel@m.gmane.org; Sun, 17 Jan 2010 08:51:22 +0100 Original-Received: from localhost ([127.0.0.1]:43062 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWPut-0003eI-21 for ged-emacs-devel@m.gmane.org; Sun, 17 Jan 2010 02:51:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWPuR-0003QO-Um for emacs-devel@gnu.org; Sun, 17 Jan 2010 02:50:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWPuO-0003NP-3D for emacs-devel@gnu.org; Sun, 17 Jan 2010 02:50:55 -0500 Original-Received: from [199.232.76.173] (port=58355 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWPuN-0003N8-G8 for emacs-devel@gnu.org; Sun, 17 Jan 2010 02:50:51 -0500 Original-Received: from mx20.gnu.org ([199.232.41.8]:53390) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NWPuM-0006ac-PN for emacs-devel@gnu.org; Sun, 17 Jan 2010 02:50:51 -0500 Original-Received: from poseidon.ceid.upatras.gr ([150.140.141.169]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWPuK-0003LC-NH for emacs-devel@gnu.org; Sun, 17 Jan 2010 02:50:49 -0500 Original-Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 496ADEB47F6; Sun, 17 Jan 2010 09:50:46 +0200 (EET) Original-Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 3D566160F71; Sun, 17 Jan 2010 09:50:46 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Original-Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNABFjh5xOCn; Sun, 17 Jan 2010 09:50:46 +0200 (EET) Original-Received: from kobe.laptop (ppp-94-64-194-150.home.otenet.gr [94.64.194.150]) by mail.ceid.upatras.gr (Postfix) with ESMTP id CA537160F6D; Sun, 17 Jan 2010 09:50:45 +0200 (EET) Original-Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id o0H7oiSf004601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 09:50:44 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id o0H7ohZf004598; Sun, 17 Jan 2010 09:50:43 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) In-Reply-To: <20100116213821.GB6676@muc.de> (Alan Mackenzie's message of "Sat, 16 Jan 2010 21:38:21 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (berkeley-unix) X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 3) 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:120137 Archived-At: On Sat, 16 Jan 2010 21:38:21 +0000, Alan Mackenzie wrote: > On Sat, Jan 16, 2010 at 04:37:24AM +0200, Giorgos Keramidas wrote: >> On Fri, 15 Jan 2010 22:27:24 +0000, Alan Mackenzie wrote: >> > When I execute bzr status, it gives me a list of ~55 allegedly modified >> > files, finishing up with: > >> > pending merge tips: (use -v to see all merge revisions) >> > Jan D. 2010-01-06 [merge] Fix slowdown and wrong font choosed by XSETTINGS... > >> > Would somebody please tell me what I might have done to make bzr think >> > I've got 55 modified files? How might I recover from this? > >> The "pending merge" message means that in the past (before you made the >> quick fix to the two files) you did: > >> bzr merge > > OK, that's quite likely. Am I right believing that 'bzr merge' pulls in > any changes in the current branch's parent? Hi Alan, Yes, you are right. "bzr merge" pulls changes from the parent branch. This means that if you have committed local changes in 'quickfixes', the history DAG of the quickfixes branch looks like this: ... o --- o --- o --- X (local change) \ `----- o --- o --- Y (last parent branch changeset) After "bzr merge" has pulled the changes at the bottom of this history DAG it then tries to merge these changes with the state of the current working directory. The final result of a successful "bzr merge" command is then a working directory that refers to _both_ the parent changes (your "X" local change and the latest changeset in the parent branch (Y in this case). Before you "bzr commit" a merged state the history DAG is ... o --- o --- o --- X =================== W \ // `----- o --- o --- Y ===// where the double lines represent the uncommitted state of the "merge" you just performed. This merge is *not* recorded into the metadata of the branch yet, so you have to follow "bzr merge" with "bzr commit" to complete this operation: ... o --- o --- o --- X ------------------- W \ / `----- o --- o --- Y ---/ This will record the locally merged files as a new changeset and you will be able to "bzr push" to the parent branch. The "bzr push" will then be able to send the X and W changesets to the parent branch. In terms similar to what CVS does, the two commands -- "bzr merge" and "bzr commit" --- perform operations similar to "cvs update" and "cvs commit". * The "bzr merge" command pulls changes from the parent branch, stores them in the .bzr metadata of the local branch and also tries to apply the changes it just pulled to the files of the working directory. Conflicts may arise at this point, precisely as they did for "cvs update". * When all conflicts are resolved, "bzr commit" stores the resolved state of all files in the .bzr/ area of the local branch. A "push" can then send them to the parent branch. >> I think the easiest way to revert your local "quickfixes" branch to a >> known & sane state is something like: >> >> 1. Keep a backup of the two files you modified. >> 2. Wipe the local quickfixes branch. >> 3. Re-create the quickfixes from trunk. >> 4. Overwre the two files in the new quickfixes branch. >> 5. Use "bzr diff" to inspect the changes. >> 6. Commit them with "bzr commit". > > Do I want to revert it? I don't think I do. If I just do "bzr > commit" in my .../quickfixes, that should leave it in a consistent > state, shouldn't it? > > After that, I want to get my changes from .../quickfixes copied over > to .../trunk. Is 'bzr push' the way to do this? The choice of "revert" was a poor one. I didn't mean "revert" as in "lose your local changes to the two files you edited manually, but more like "finish the pending merge and allow more commits to this branch". Stephen J. Turnbull has posted an easier method for restoring sanity to the quickfixes branch, using "bzr shelve". Now that I have read about it and tried it in a small sample branch at home, I think it's probably better to avoid trashing the quickfixes branch and use Stephen's recommendation.