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: Help me unstick my bzr, please. Date: Sat, 16 Jan 2010 11:54:41 +0200 Message-ID: <83d41acr32.fsf@gnu.org> References: <20100115222724.GB1931@muc.de> <87r5pqkc63.fsf@kobe.laptop> <83k4vicwws.fsf@gnu.org> 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 1263635712 2706 80.91.229.12 (16 Jan 2010 09:55:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Jan 2010 09:55:12 +0000 (UTC) Cc: keramida@ceid.upatras.gr, acm@muc.de, emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 16 10:55:04 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 1NW5N1-0004r9-Rs for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 10:55:04 +0100 Original-Received: from localhost ([127.0.0.1]:51100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW5N2-0001sq-LR for ged-emacs-devel@m.gmane.org; Sat, 16 Jan 2010 04:55:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NW5M5-00016t-UB for emacs-devel@gnu.org; Sat, 16 Jan 2010 04:54:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NW5M1-00012R-25 for emacs-devel@gnu.org; Sat, 16 Jan 2010 04:54:05 -0500 Original-Received: from [199.232.76.173] (port=60516 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NW5M0-00012H-Rg for emacs-devel@gnu.org; Sat, 16 Jan 2010 04:54:00 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:53755) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NW5M0-0005zC-8R for emacs-devel@gnu.org; Sat, 16 Jan 2010 04:54:00 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0KWC00J0039NJA00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 16 Jan 2010 11:53:59 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.60.183]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KWC00EPV3HYSJC0@a-mtaout22.012.net.il>; Sat, 16 Jan 2010 11:53:59 +0200 (IST) In-reply-to: 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:120101 Archived-At: > From: Lennart Borgman > Date: Sat, 16 Jan 2010 10:16:37 +0100 > Cc: Giorgos Keramidas , acm@muc.de, emacs= -devel@gnu.org >=20 > On Sat, Jan 16, 2010 at 8:48 AM, Eli Zaretskii wrote= : > >> > >> > When I execute bzr status, it gives me a list of ~55 allegedly= modified > >> > files, finishing up with: > >> > > >> > =C2=A0 =C2=A0 pending merge tips: (use -v to see all merge rev= isions) > >> > =C2=A0 =C2=A0 =C2=A0 Jan D. 2010-01-06 [merge] Fix slowdown an= d wrong font choosed by XSETTINGS... > >> > > >> > Would somebody please tell me what I might have done to make b= zr think > >> > I've got 55 modified files? =C2=A0How might I recover from thi= s? > >> > >> The "pending merge" message means that in the past (before you m= ade the > >> quick fix to the two files) you did: > >> > >> =C2=A0 =C2=A0 bzr merge > >> > >> This pulled stuff from the local trunk branch, and merged it wit= h your > >> local quickfixes branch. =C2=A0But you have to also run "bzr com= mit" to > >> complete the fix. =C2=A0You didn't at the time, so the quickfixe= s branch > >> remains in a "the merge has locally finished but it is uncommitt= ed" > >> state. > > > > That's probably what happened. >=20 >=20 > I do not understand. Can someone please explain to me why a bazaar > user have to take care of this? It's in the workflow described on the wiki: the process of merging a branch with the mainline involves two commands: bzr merge bzr commit The first one merges the text of the files, but does not combine thei= r histories. The second command finishes the merging process by updating the history so that it now includes both local commits and whatever happened in the mainline since the last time you merged from it. Note that there could be conflicts reported by "bzr merge", in which case you should resolve them manually, then use a 3rd command to tell Bazaar that the conflicts were resolved: bzr resolve file1 file2 file3 ... where the named files are those where you resolved the conflicts. This 3rd command should come between "bzr merge" (which reports the conflicts in the first place) and "bzr commit". These complications are the reason why IMO using a separate branch fo= r ``quick fixes'' is not the best way. Doing such simple changes directly in the trunk, or in a separate branch that is bound to the remote repository, is much better. The latest version of BzrForEmacsDevs page on the wiki suggest these latter 2 possibilities= , but Alan is using the previous suggestion, whereby the quickfixes branch was a local branch with the trunk mirror its parent. The workflow with a local branch whose parent is the trunk mirror is IMO better suited to working on a non-trivial set of changes or a new feature. That's because this kind of job is probably not finished in one go, and you need to return to it in the course of several days or even weeks. So you will want to be isolated from changes on the trun= k for a while. Also, separating feature development into a separate branch will allow you to make simple unrelated changes on the trunk a= t the same time, without having your local changes get in your way. With such a significant development branch, the overhead of merging =66rom the trunk from time to time is justified. With simple changes= , it is not, IMO.