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: Merging emacs-23 into trunk Date: Thu, 11 Nov 2010 11:52:38 +0900 Message-ID: <87vd44efm1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <837hglf61k.fsf@gnu.org> <8362w5f0lx.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1289443843 26431 80.91.229.12 (11 Nov 2010 02:50:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 11 Nov 2010 02:50:43 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 11 03:50:35 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.69) (envelope-from ) id 1PGNFD-0004C5-5k for ged-emacs-devel@m.gmane.org; Thu, 11 Nov 2010 03:50:35 +0100 Original-Received: from localhost ([127.0.0.1]:51383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGNFC-0006yD-LI for ged-emacs-devel@m.gmane.org; Wed, 10 Nov 2010 21:50:34 -0500 Original-Received: from [140.186.70.92] (port=52211 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGNF7-0006y5-TC for emacs-devel@gnu.org; Wed, 10 Nov 2010 21:50:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGNF6-0005TS-Ow for emacs-devel@gnu.org; Wed, 10 Nov 2010 21:50:29 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:39490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGNF4-0005Sr-NT; Wed, 10 Nov 2010 21:50:27 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id EFA8F2AF543; Thu, 11 Nov 2010 11:50:24 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id DEA562AF542; Thu, 11 Nov 2010 11:50:24 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D9DC13FA04CA; Thu, 11 Nov 2010 11:50:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9178E11EF63; Thu, 11 Nov 2010 11:52:38 +0900 (JST) In-Reply-To: <8362w5f0lx.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.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:132530 Archived-At: Eli Zaretskii writes: > > Actually, I'm not cherry-picking > > I think you are. From the docs of "bzr merge": You of all people whould know better than to trust the Bazaar docs! There are two different, though closely related, definitions, of "cherrypicking" in practice. Definition 1, "merging individual revisions, or a subset of available revisions", is the one used by the Bazaar documents and the Bazaar developers. Definition 2, which is the one Stefan is implicitly using, is "merging individual revisions, or a subset of available revisions, *forcing the VCS to forget* associations between changes and revisions." (My wording is a bit awkward because this subtlety is almost never made explicit; this is the first time I've tried.) In the DAG-oriented VCSes (git, Mercurial, Bazaar), there is no practical difference because once you ask for an out-of-order patch application the DAG no longer applies simplistically; in particular, you can't compute the ancestor for a three-way merge. By design they forget. ("git filter-branch" and "git rebase --interactive" are hacks allowing you to provide the necessary information out-of-DAG.) GNU Arch (and Darcs) know which changes have been applied to the tree; there is no presumption that they are applied in history-determined subsets. (The difference between Arch and Darcs is that Arch required the user to try applying and then resolve conflicts at the changeset level, one after another; Darcs is smart enough to compute where conflicts will occur, and it then rearranges hunk order to maximize automatic application before asking the user to resolve conflicts.) Stefan, who is familiar with both GNU Arch and Darcs, I believe, correctly perceives Bazaar behavior as a huge regression vs. Arch in this respect.