From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Removing rollback from VC mode - request for comment Date: Thu, 11 Dec 2014 13:36:49 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20141211183649.GE581@thyrsus.com> References: <20141211092138.6D5F6C008E@snark.thyrsus.com> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1418323139 11034 80.91.229.3 (11 Dec 2014 18:38:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 18:38:59 +0000 (UTC) Cc: "Eric S. Raymond" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 19:38:53 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 1Xz8dY-0007Ui-H8 for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 19:38:52 +0100 Original-Received: from localhost ([::1]:53127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz8dY-0007lw-2v for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 13:38:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz8cL-0006Zh-Ez for emacs-devel@gnu.org; Thu, 11 Dec 2014 13:38:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xz8ba-0002sl-3g for emacs-devel@gnu.org; Thu, 11 Dec 2014 13:37:37 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:38707 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz8ba-0002sA-0Z for emacs-devel@gnu.org; Thu, 11 Dec 2014 13:36:50 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 8255EC0092; Thu, 11 Dec 2014 13:36:49 -0500 (EST) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 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:179815 Archived-At: Stefan Monnier : > > Rollback is a case in point. It is a command that lets you undo the > > last checkin. Only SCCS and RCS actually support it. Git possibly > > could, in theory, but the Git implementation would be tricky and have > > sharp edges when the last revision had been pushed. > > Actually, I think most VCS can support it one way or another. It's not hard to simulate using what in git terms is a reverse cherry pick. But modifying history in place is very difficult to do with a good outcome. > But contrary to what the above two statements might lead you to think, > I'm in favor of removing this rollback, because I don't think it's good > enough as it stands. E.g. I think it should be replaced by an > `uncommit' which would be the opposite of `commit' and should ideally > preserve as much info as possible (e.g. not change the file's contents, > and stash the commit message somewhere so it can be re-used if you > decide to recommit). Interesting idea. I think you are right that this is what people usually want - "oops, I just committed something incomplete, let me get back to the repo and workfile state just before I hit the button, with the commit message stashed for re-use". The question then becomes whether preserving the rollback methods we have now gets us anywhere towards that. /me reads the code for vc-rcs-rollback. And the answer is..no, not really. The RCS backend code for coping at a branch base might be slightly useful, but the rest is designed for a different UI and would have to be tossed out anyway. Conclusion: rollback should indeed be scrapped, and uncommit added to the list of features to be done along with stash/shelve support. It'll take a while, though. Michael Albinus and I are finding a lot of bit-rot. He just told me that six of the eight working-revision backend functions don't work right. Much repair is required before adding new features. -- Eric S. Raymond