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: Tue, 22 Sep 2015 09:26:12 +0900 Message-ID: <87y4fzmh97.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <56000DEB.1000306@yandex.ru> <83si67n4ch.fsf@gnu.org> <5600373A.6090206@yandex.ru> <83oagvn1lz.fsf@gnu.org> <56003D57.2080102@yandex.ru> <83lhbzmvhq.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 1442881594 15468 80.91.229.3 (22 Sep 2015 00:26:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 00:26:34 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 22 02:26:26 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 1ZeBPd-0001PJ-A9 for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2015 02:26:25 +0200 Original-Received: from localhost ([::1]:34991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeBPc-0000C8-DS for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 20:26:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeBPZ-0000C1-GP for emacs-devel@gnu.org; Mon, 21 Sep 2015 20:26:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeBPY-0004kD-Js for emacs-devel@gnu.org; Mon, 21 Sep 2015 20:26:21 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:56543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeBPT-0004i0-V3; Mon, 21 Sep 2015 20:26:16 -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 B2FD11C395B; Tue, 22 Sep 2015 09:26:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8B0F211EF83; Tue, 22 Sep 2015 09:26:12 +0900 (JST) In-Reply-To: <83lhbzmvhq.fsf@gnu.org> 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:190221 Archived-At: Eli Zaretskii writes: > Yes, it does. From the description of "cvs admin": But IIRC cvs admin requires shell access to the repository host: you can't use it from a client machine. > So is "cvs -o". The CVS manual says that much. Why should Git be > different? A careful user won't invoke this command unless they know > what they are doing, right? A user should not be able to invoke this command at all. > > 'git revert', by itself, doesn't affect the remote either. > > Indeed, so what is the reason not to use it as "rollback"? In git, "revert" has the wrong semantics; it adds a commit rather than removing one. This would surely confuse anybody who knows a little bit about databases. > I agree. But the original issue was whether a "rollback" should > invoke "git reset --hard", "git revert", or sometimes one and > sometimes the other. The issue never was about adding a "push" to > that. The problem is that users don't push commits. They push branches. That resets the ref on the remote end, which will confuse all derived branches that include the rolled-back commit, even if you don't get the usual rebase lossage. My personal take is that `vc-rollback' should do "git reset" (no --hard!), "hg strip", etc as available on the theory that "rollback" refers to an in-progress database operation, not the users' edits in the workspace. If the user really wants that effect, they can fullow up with a force-checkout. If you do implement it as "git reset --hard", it had better have a warning prompt like, "If you do this, you will lose all work involved in this commit, in the repo and in your workspace. Proceed?"