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: Thu, 01 Oct 2015 10:18:40 +0300 Message-ID: <83vbar9hv3.fsf@gnu.org> 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> <5602BE3E.1050009@yandex.ru> <5602C4DE.8020105@yandex.ru> <560B4899.2070708@yandex.ru> <83y4fobegc.fsf@gnu.org> <560BC73C.4040403@yandex.ru> <83d1x0atb2.fsf@gnu.org> <560C9EDA.3040207@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443708295 16513 80.91.229.3 (1 Oct 2015 14:04:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2015 14:04:55 +0000 (UTC) Cc: stephen@xemacs.org, dak@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, rms@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 01 16:04:45 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 1ZheTS-0005Cm-7x for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 16:04:42 +0200 Original-Received: from localhost ([::1]:50536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZheTR-0004gA-H9 for ged-emacs-devel@m.gmane.org; Thu, 01 Oct 2015 10:04:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhY8p-0002ju-A5 for emacs-devel@gnu.org; Thu, 01 Oct 2015 03:19:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhY8o-0008Uw-7b for emacs-devel@gnu.org; Thu, 01 Oct 2015 03:18:59 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:50539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhY8j-0008Sc-RM; Thu, 01 Oct 2015 03:18:54 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NVJ00O005NJUM00@mtaout29.012.net.il>; Thu, 01 Oct 2015 10:19:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVJ0060E5OSQRA0@mtaout29.012.net.il>; Thu, 01 Oct 2015 10:19:41 +0300 (IDT) In-reply-to: <560C9EDA.3040207@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:190543 Archived-At: > Cc: monnier@iro.umontreal.ca, rms@gnu.org, stephen@xemacs.org, dak@gnu.org, > emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 1 Oct 2015 05:47:54 +0300 > > On 09/30/2015 05:13 PM, Eli Zaretskii wrote: > > > Well, with RCS as the back-end, "register" actually commits. > > That's... odd. How does it do that before the user entered the commit > message? RCS has its default for the initial commit's log message. I think you can override that with a prefix argument, but few people do. You will see that default in many of the first commits in the Emacs repository. A short excerpt: a0cf9a6 1987-03-03 Noah Friedman Initial revision 248b25a 1987-01-22 Richard Stallman Initial revision b20cd8d 1987-01-07 Richard Stallman Initial revision 62983f7 1986-09-29 Joseph Arceneaux Initial revision bd1411a 1986-09-18 Richard Stallman Initial revision 2c4b8b1 1986-09-14 Jim Blandy Initial revision 47bdd84 1986-09-12 Jim Blandy Initial revision ff9c6df 1985-12-14 Jim Blandy Initial revision > > I see > > that the other back-ends only use the "add" sub-command, but maybe we > > should change that, so registering ends up with the files committed. > > Maybe we should just call that action "committing", and assume that > registering, if needed, is a part of it. Doing it another way would > sound pretty weird to me. Sounds good to me, modulo existing habits. > > I don't think there are such back-ends. The only issue with such a > > change that I see is that people might want adding files > > incrementally, then committing them all at once. If this is something > > users might do a lot, perhaps we should have a defcustom for such > > behavior. > > Git users are accustomed to 'git add' moving changes to the staging > area, which is pretty neat, but one needs to 'git add' both unregistered > files *and* files that simply have new changes. That's mismatch #1. > > Mismatch #2 is that no other VCS (AFAIK) has a staging area. So it's > much simpler to avoid that intermediate step, since it can't be > implemented in a generic fashion. I agree. > > I agree, but the features in question do make sense, I think, because > > the back-ends they were written for still exist and are supported and > > used. > > That would imply that e.g. every Git or Hg feature makes sense in VC. > But we only support those we can abstract over in a reasonable fashion. I was talking specifically about features that existed for a long time. Introduction of new features is, of course, another matter, and I agree with you that not every feature of every VCS should be in VC.