From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: RCS, again: another removed functionality: undo last-checkin Date: Wed, 30 Sep 2015 05:27:37 +0300 Message-ID: <560B4899.2070708@yandex.ru> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1443649370 5895 80.91.229.3 (30 Sep 2015 21:42:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Sep 2015 21:42:50 +0000 (UTC) Cc: "Stephen J. Turnbull" , dak@gnu.org, eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 30 23:42:44 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 1ZhP99-0001pl-P8 for ged-emacs-devel@m.gmane.org; Wed, 30 Sep 2015 23:42:43 +0200 Original-Received: from localhost ([::1]:33743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhP99-0002tX-4n for ged-emacs-devel@m.gmane.org; Wed, 30 Sep 2015 17:42:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh77d-00008F-BK for emacs-devel@gnu.org; Tue, 29 Sep 2015 22:27:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zh77Z-00035j-9r for emacs-devel@gnu.org; Tue, 29 Sep 2015 22:27:57 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:37481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zh77Z-00035R-3L; Tue, 29 Sep 2015 22:27:53 -0400 Original-Received: by wicfx3 with SMTP id fx3so40904467wic.0; Tue, 29 Sep 2015 19:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4/EIwVhCOrkrvtdeB4rlheIB23bSrbvZHs6+Bw0vS2k=; b=rhP9ag3tXTerJb291Qj1tgijc4kRyjwLpPYWgKUHrt91sWvDkBdvBOjDz1+vsh9X2K A6cXmP3ZKn/6/KEcIulDVm0YXinDletkCgi/t7NJpmacQ5e+RTfOeqf8GhxvPE2JOD/u b9YVUoJdwZNGxr50pu6Pvn+MU8AroCtE4LepamJpsLVMY3NuAP7dzoMgguH1khyuH0V4 En/2NSw5fscgasgMURrUuaQzTImSWKpIwpo4NsdS3jVOoc/yieYMATkXH2mqNVz06GyY etuO7nTmJ4abnLPwHa8J5HaMhgoBroPREPkputn+TelIJINh7n5YXppL6Yj3CDKdVRUR pZpg== X-Received: by 10.180.86.232 with SMTP id s8mr1895789wiz.27.1443580072104; Tue, 29 Sep 2015 19:27:52 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id ly4sm26845188wjb.4.2015.09.29.19.27.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 19:27:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Thunderbird/41.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b 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:190488 Archived-At: On 09/23/2015 08:33 PM, Stefan Monnier wrote: >>> Yes, M-x vc-commit RET should definitely ignore the "up to date" status. >> By vc-commit, do you mean vc-next-action, or a new command? > > Nowadays (as in "with modern VCS"), vc-next-action can't do much > beside commit, and `vc-next-action' is also the only command which > can do "commit". It also performs that weird step: "If every file in the VC fileset is not registered for version control, register the fileset (but don't commit)", aborting if some of the files in the fileset are unregistered and others are registered. It would make sense to remove it (and commit all selected files), but it would be nice to know what prompted its existence in the first place. This could also be dropped (we have a separate command for it): "For a centralized version control system, if any work file in the VC fileset is out of date, offer to update the fileset." > So, yes, I mean a new command (which should mostly supercede > vc-next-action). The section dedicated to "For old-style locking-based version control systems" in vc-next-action's docstring is more convoluted. As long as we're dedicated to supporting them, I'm not sure what change would be appropriate.