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: Strange response after merge from upstream Date: Wed, 02 Dec 2009 05:56:35 +0100 Message-ID: <87bpii55z0.fsf@telefonica.net> References: <833a3umrfx.fsf@gnu.org> <83skbuko4g.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 1259729845 21948 80.91.229.12 (2 Dec 2009 04:57:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Dec 2009 04:57:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 02 05:57:18 2009 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 1NFhHB-0000Za-Nn for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2009 05:57:18 +0100 Original-Received: from localhost ([127.0.0.1]:38550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFhHB-0000p5-Ad for ged-emacs-devel@m.gmane.org; Tue, 01 Dec 2009 23:57:17 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFhH5-0000oN-CG for emacs-devel@gnu.org; Tue, 01 Dec 2009 23:57:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFhH1-0000lY-M8 for emacs-devel@gnu.org; Tue, 01 Dec 2009 23:57:11 -0500 Original-Received: from [199.232.76.173] (port=35926 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFhH1-0000lV-K3 for emacs-devel@gnu.org; Tue, 01 Dec 2009 23:57:07 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:48725) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFhH0-0007hP-Sv for emacs-devel@gnu.org; Tue, 01 Dec 2009 23:57:07 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NFhGy-0000WA-3J for emacs-devel@gnu.org; Wed, 02 Dec 2009 05:57:04 +0100 Original-Received: from 112.red-83-38-73.dynamicip.rima-tde.net ([83.38.73.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Dec 2009 05:57:04 +0100 Original-Received: from ofv by 112.red-83-38-73.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Dec 2009 05:57:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 112.red-83-38-73.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:GHswIAGPn3yrgsTTzDFGNhGkpCo= 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:118114 Archived-At: Eli Zaretskii writes: > I understand that, but that commit was because merge by itself does > not commit the changes I pulled from the mainline. Without the > commit, bzr was even less happy. > > I guess I expected to see nothing from "missing" after these > operations, since really the branch is an exact copy of the upstream. > Evidently, that's not "missing"'s logic and purpose. "bzr diff" did > come up empty-handed, as expected. On one branch you used `pull', which adds revisions on top of those you previously had. So if you pulled 10 revisions, you have 10 more revisions on the history of that branch. On the other branch you merged the missing revisions and then you had to commit the merge after resolving conflicts, if any. You end with 10 revisions coming from the parent branch plus one revision from your commit totalling 11. If the source tree ends being indentical on both cases, it is just by chance. Nothing prevents you from editing the files before the post-merge commit. The key here is that the final history of those branches allows them to contain different working files, i.e. you can't guarantee that the branches have not diverged looking at the set of revisions they contain and how they arranged on its DAG. One branch has a revision that is unknown by the other. As you probably already know, each revision has a revision-id that makes it unique and is used for checking its existence on a branch, no matter if it was originated there or arrived via pull or merge. That two branches ends containing the same source code is irrelevant if the revisions they contain and their arrangement on the respective DAGs makes the branches non-equivalent. >> You may want to use `bzr merge --pull` to get equivalent of git >> fast-forward merge. merge --pull will pull new changes from other >> branch if possible, thus make your branch a copy of the other >> branch. Or it will do merge when 2 branches are diverged, i.e. both >> branches has new commits, not present in other branch. > > I don't know git. How is "merge --pull" different from merge followed > by commit? merge -pull does this: if branches-diverged? yes: merge (you need to explicitly commit afterwards) no : pull (no need to commit) > would it avoid the "1 extra revision" in the output of "missing"? Yes, because your quickfixes/ branch did not diverged from the branch you pulled from, so it will do a `pull', like you did on your trunk branch. -- Óscar