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: [Emacs-diffs] trunk r117980: Merge from emacs-24; up to r117522. Date: Wed, 01 Oct 2014 11:52:58 +0900 Message-ID: <87sij8v6ut.fsf@uwakimon.sk.tsukuba.ac.jp> References: <23194.1412094213@olgas.newt.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412132025 19705 80.91.229.3 (1 Oct 2014 02:53:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 02:53:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 01 04:53:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZA2r-00080Q-Qx for ged-emacs-devel@m.gmane.org; Wed, 01 Oct 2014 04:53:37 +0200 Original-Received: from localhost ([::1]:47526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZA2r-0000QR-Eh for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 22:53:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZA2V-0000Q3-Hx for emacs-devel@gnu.org; Tue, 30 Sep 2014 22:53:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZA2O-0001KO-0y for emacs-devel@gnu.org; Tue, 30 Sep 2014 22:53:15 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:54816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZA2N-0001J5-MZ for emacs-devel@gnu.org; Tue, 30 Sep 2014 22:53:07 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7D0241C39BC; Wed, 1 Oct 2014 11:52:58 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 710451A2697; Wed, 1 Oct 2014 11:52:58 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174894 Archived-At: Stefan Monnier writes: > Sadly, the only DVCS which knew how to keep track of partial (aka > cherry-picked) merges were DaRCS and Arch, AFAIK. But in those DVCSes you lose the DAG, and gain exponential behavior for your trouble. (Speaking of Darcs in the past tense isn't very accurate, either, although at the moment they're in maintenance mode.) Tom Lord's revc (aka Arch v3) was showing theoretical promise in this direction: he based object storage (Arch's revision archive) on git's, but also was able to manipulate changes (revid pairs). I'm not sure if he planned to add token replacement and similar Darcs-y features. > FWIW, Git suffers from the same problem, AFAIK. Tho maybe Git has found > a clever way to handle them OK in practice, even though it doesn't > actually keep track of them either (along the lines of what it does for > file renames). No, there's no trick in git for this. It's just that the git community has a culture of rebasing that is much more tolerant of loss of actual history (as seen by the developer in a private workspace) as long as the notional history (post rebase and pushed to public) makes sense to the community. In this view, a cherry-pick is sort of viewed as a "reinvention" of the patch, even though it's actually a copy. It's possible to do the equivalent of "bzr merge -i" in git using filter-branch, but it's somewhat complex and there's no built-in command for it. git just counts on the locality of commits in a branch (ie, commits different branches touch the same code infrequently) when doing a three-way merge. I don't think a patch-tracking VCS like Darcs would do a better job, though -- you'd end up with a conflict in that case too. For future reference: Git has an option to cherry-pick which inserts the revision[1] cherry-picked in the commit log automatically. I believe that changed from default on to default off years ago, though. So I guess it wasn't considered as useful as saving bytes (and lines in log message displays). As Eli points out, it's *not* recorded in the DAG, maybe that's why. Footnotes: [1] Indicating the change relative to the parent, not the state of the tree.