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: Thu, 02 Oct 2014 10:48:15 +0900 Message-ID: <87egurutr4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <23194.1412094213@olgas.newt.com> <87sij8v6ut.fsf@uwakimon.sk.tsukuba.ac.jp> <83tx3nkfy3.fsf@gnu.org> <83lhozkd4l.fsf@gnu.org> <83k34jkcxy.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412214525 20499 80.91.229.3 (2 Oct 2014 01:48:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Oct 2014 01:48:45 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, yuri.v.khan@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 02 03:48: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 1XZVVW-0003Bx-B9 for ged-emacs-devel@m.gmane.org; Thu, 02 Oct 2014 03:48:38 +0200 Original-Received: from localhost ([::1]:59659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZVVV-0003Nt-PU for ged-emacs-devel@m.gmane.org; Wed, 01 Oct 2014 21:48:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZVVN-0003Mb-M1 for emacs-devel@gnu.org; Wed, 01 Oct 2014 21:48:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZVVI-0004LV-TZ for emacs-devel@gnu.org; Wed, 01 Oct 2014 21:48:29 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:57659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZVVD-00049f-Ic; Wed, 01 Oct 2014 21:48:19 -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 5B1C11C3A0D; Thu, 2 Oct 2014 10:48:15 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4D06D1A2697; Thu, 2 Oct 2014 10:48:15 +0900 (JST) In-Reply-To: <83k34jkcxy.fsf@gnu.org> 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:174920 Archived-At: Eli Zaretskii writes: > > Date: Wed, 01 Oct 2014 18:45:14 +0300 > > From: Eli Zaretskii > > Cc: stephen@xemacs.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > > > * Imagine a mergy graph on the branch being cherry-picked from. How do > > > you revert that mergy clump? What if there are merges from that into > > > the current branch? > > > > > > ---o---o---o---o---o---o A > > > \ / > > > o---o---o---o B > > > \ / > > > o---o > > > > Well, figure it out, and you get my thumbs-up! > > Btw, it's a bit ironic that while there's a lot of pressure to rebase > branches instead of merging them, when these issues are discussed, > suddenly all kind of complex DAGs pop up all over the place. If > rebasing is the word of the day, then you will almost never see such > DAGs. I don't see the irony yet (the people who push rebasing are not necessarily the same people who are explaining the technology), but that's probably because I explain this as a difference of culture in the git community vs. the Bazaar community.[1] Same point, different point of view. The real problem as Stefan points out is that in these VCSes the source of a cherry-pick is *not* part of the formal metadata of the new commit (git cherry-pick -x is a typical *in*formal way to record the information). Git does have a (rarely used AFAIK) concept of "grafts", which are an out of band record of equivalent (as revisions) commits. This doesn't work terribly well (if the commits point to different trees, the relation is actually asymmetric), and is mostly useful in cases where filter-branch is used to remove some commits near the root of the DAG, but does not affect the trees (ie, it just reparents downstream commits to earlier ancestors). What we want here is a way to equivalence changes. The obvious representation of a change would be the corresponding SHA1 pair. (However, as Darcs points out, there are useful "patches" that have effects that cannot be reproduced using diff and patch (and the token-replace patch is actually implemented in Darcs). Whether those patch types are "useful enough" probably depends on the language, the project, and the programmers.) Then the question would be how to use that information later. Git developers evidently don't have an idea or have an idea but decided it wasn't terribly useful compared to the alternative (merge when you care about history-in-place, rebase when you don't, where "you" refers to a project-wide consensus or it all falls down). Footnotes: [1] Speaking of irony, has anybody else noticed the irony of calling the bzr development process "Bazaar"?