From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: RCS, again: another removed functionality: undo last-checkin Date: Tue, 22 Sep 2015 09:16:29 +0300 Message-ID: <83d1xbm11e.fsf@gnu.org> 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> <87y4fzmh97.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442902614 9331 80.91.229.3 (22 Sep 2015 06:16:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 06:16:54 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 22 08:16:42 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 1ZeGsb-0000VH-Bw for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2015 08:16:41 +0200 Original-Received: from localhost ([::1]:36859 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeGsa-0004oP-Vo for ged-emacs-devel@m.gmane.org; Tue, 22 Sep 2015 02:16:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeGsL-0004o7-MJ for emacs-devel@gnu.org; Tue, 22 Sep 2015 02:16:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeGsI-0003vU-Dg for emacs-devel@gnu.org; Tue, 22 Sep 2015 02:16:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeGsI-0003vQ-5G for emacs-devel@gnu.org; Tue, 22 Sep 2015 02:16:22 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NV200800EOZZX00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 22 Sep 2015 09:16:20 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV2008T0ER6TB50@a-mtaout22.012.net.il>; Tue, 22 Sep 2015 09:16:20 +0300 (IDT) In-reply-to: <87y4fzmh97.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:190225 Archived-At: > From: "Stephen J. Turnbull" > Cc: Dmitry Gutov , > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Tue, 22 Sep 2015 09:26:12 +0900 > > 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. I think you are wrong (I think I used it once or twice on a client), but my CVS is rusty. > > > '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. But that's the only sane thing to do when a commit was pushed. > > 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. Since 'revert' just adds another commit, I don't see why they will be confused.