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: Removing rollback from VC mode - request for comment Date: Fri, 12 Dec 2014 09:57:35 +0900 Message-ID: <871to5hegw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141211092138.6D5F6C008E@snark.thyrsus.com> <874mt2iksu.fsf@fencepost.gnu.org> <87fvcm8jf0.fsf@zigzag.favinet> <20141211125145.GB25499@thyrsus.com> <83d27qtar6.fsf@gnu.org> <20141211174508.GC581@thyrsus.com> <20141211214938.GA3216@thyrsus.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1418345895 20237 80.91.229.3 (12 Dec 2014 00:58:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2014 00:58:15 +0000 (UTC) Cc: Sergey Organov , emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 12 01:58:08 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 1XzEYZ-0004zu-Vg for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2014 01:58:08 +0100 Original-Received: from localhost ([::1]:54878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzEYY-00054h-TL for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 19:58:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzEYD-00054c-Fo for emacs-devel@gnu.org; Thu, 11 Dec 2014 19:57:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzEY5-0000HV-Vp for emacs-devel@gnu.org; Thu, 11 Dec 2014 19:57:45 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:34204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzEY5-0000H9-M9 for emacs-devel@gnu.org; Thu, 11 Dec 2014 19:57:37 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4A0DA1C39A8; Fri, 12 Dec 2014 09:57:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2F3A61A2CFC; Fri, 12 Dec 2014 09:57:35 +0900 (JST) In-Reply-To: <20141211214938.GA3216@thyrsus.com> 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:179853 Archived-At: Eric S. Raymond writes: > Rebase is a different operation. It's forward composition after > you've chopped off a last segnment. And? Certainly, there are several ways you could define "commit deletion", but this is equally certainly one of the reasonable ones. > It's...quite different. I had to wrestle with this when implementing > commit deletion in reposurgeon. There are at least three concepts of commit deletion. All are implemented in git. The first is removing the effects on content but not the history in the DAG. git implements the command "revert" for this purpose.[1] The second removes both the effects and the history. git implements the command "rebase" for this purpose. Finally, one may wish to remove the history, but not the effects. git (in its gittishly inimitable way) provides several ways to accomplish this: the "squash" operation of the "rebase --interactive" command, the "--squash" option to the "merge" command, and the ultimate generalization of all of the above, the "filter-branch" command. In git-like DAG implementations, all history alterations require recreation of "forward history" as well. It's theoretically possible to equivalence commits (eg, git provides grafts) but as far as I know there are no VCSes that try to do this automatically and consistently through all DAG operations. That is indeed a hard problem. Bottom line, in existing DAG-based VCSes, there is either no way to actually remove commits, or the human keeps track of the equivalencing of descendant commits in lieu of a Sufficiently Smart VCS. Footnotes: [1] Introspection suggests that "commit deletion" is a bad way to describe this. I don't know for sure that others feel that way, and I include it for symmetry/completeness.