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: RCS, again: another removed functionality: undo last-checkin Date: Wed, 23 Sep 2015 23:38:27 +0900 Message-ID: <87io71dwv0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> <83k2rknr2c.fsf@gnu.org> <87mvwellmg.fsf@uwakimon.sk.tsukuba.ac.jp> <56023A6C.3020302@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1443019150 17989 80.91.229.3 (23 Sep 2015 14:39:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 14:39:10 +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 Sep 23 16:38:56 2015 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 1ZelCB-00027x-BI for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 16:38:55 +0200 Original-Received: from localhost ([::1]:48231 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZelCA-0004k9-AG for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2015 10:38:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZelBs-0004jp-Dd for emacs-devel@gnu.org; Wed, 23 Sep 2015 10:38:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZelBp-0002cy-8Q for emacs-devel@gnu.org; Wed, 23 Sep 2015 10:38:36 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:58117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZelBo-0002cB-Vi for emacs-devel@gnu.org; Wed, 23 Sep 2015 10:38:33 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9A40C1C398C; Wed, 23 Sep 2015 23:38:27 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6F0B611EF83; Wed, 23 Sep 2015 23:38:27 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" cb65bfaf7110 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:190288 Archived-At: Stefan Monnier writes: > The "revert" (which IIUC just installs a new change which undoes the > effect of some earlier change) can mostly be implemented in > a backend-independent way. As mentioned, that's git terminology; other VCSes use that name for different operations: hg and bzr check out individual files as of some revision -- no commit takes place. For the effect of "git revert", I believe hg uses "backout", bzr uses a "merge" variant. > But the "rollback" (which IIUC can destructively remove an previous > existing commit, I guess I'd call it "uncommit") git has no command to destructively remove commits (except gc --prune, which by default gives a 60-day grace period IIRC). "git reset" simply move the HEAD pointer, and the current branch head if there is one. In hg, "rollback" and "strip" are destructive (the commit no longer exists in the repo), with the caveat that "strip" saves a patch bundle that can be restored. (I think it contains enough information to reproduce the commit.) bzr "uncommit" appears to be destructive, although if you save off the revids (not the revno!), you may be able to merge it back using that information. (Untested; on consideration, it's likely that "uncommit" alters the DAG so that the commits cannot be recovered.) > is a lot more problematic, since various backends support it in > very different ways with very different limitations. Generalizing > the "Amend:" support of vc-git.el to other backends would probably > cover 99% of the use cases. Mercurial has "commit --amend", similar to the command of the same name of git's. For bzr, I would guess you need to uncommit then commit again (dunno, but I couldn't find a command documented in bzr help, although Google finds RFEs for "commit --amend" and "recommit"). LP has a bug with a nice description of the workflow for bzr: https://bugs.launchpad.net/bzr/+bug/507529.