From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: RCS, again: another removed functionality: undo last-checkin Date: Mon, 21 Sep 2015 09:25:33 +0200 Message-ID: <87eghsfd3m.fsf@fencepost.gnu.org> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442820356 5017 80.91.229.3 (21 Sep 2015 07:25:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 07:25:56 +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 Mon Sep 21 09:25:53 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 1ZdvTz-0003Mh-PI for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 09:25:51 +0200 Original-Received: from localhost ([::1]:56282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdvTy-0002RD-V8 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 03:25:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46090) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdvTk-0002Qm-DJ for emacs-devel@gnu.org; Mon, 21 Sep 2015 03:25:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdvTj-0007LV-7f for emacs-devel@gnu.org; Mon, 21 Sep 2015 03:25:36 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdvTj-0007LF-2E; Mon, 21 Sep 2015 03:25:35 -0400 Original-Received: from localhost ([127.0.0.1]:46530 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZdvTi-00035s-6B; Mon, 21 Sep 2015 03:25:34 -0400 Original-Received: by lola (Postfix, from userid 1000) id 6EF8CDF40C; Mon, 21 Sep 2015 09:25:33 +0200 (CEST) In-Reply-To: <83si68nu4i.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 09:50:37 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:190175 Archived-At: Eli Zaretskii writes: >> From: Dmitry Gutov >> Date: Mon, 21 Sep 2015 02:24:22 +0300 >> >> On 09/20/2015 07:30 PM, Stefan Monnier wrote: >> >> > The most natural way to re-add tihs feature is to make vc-rcs.el >> > understand the "Amend:" header that's also used by Git. >> >> The use case may be similar, but the name "rollback" sounds much closer >> to what happen when you call 'git reset [--hard]'. Which is a useful >> operation as well, one currently not supported by VC. > > If the commit was already pushed, you will need "git revert" instead, > I think. That depends on whether you are working on a branch considered to have dependable commits or a preparatory/review branch. People are expected to deal with warped histories on preparatory branches. As an example, LilyPond works with a "staging" branch and a "master" branch. "master" only moves forward: once a commit is in there, it stays. If its effects are to be annulled, it is reverted. Nobody pushes to master though. Any changes are instead pushed to staging. An automated task picks up staging every few hours and if it has progressed ahead of master, it makes a complete build of the state of staging, a documentation build, a run of all regtests, and when all of that succeeds, it pushes the tested state on top of master (only as a fast-forward, otherwise it fails. And it also tests that the current state of staging is the same or strictly ahead of the tested state, so you can "stop the clock" any time before the automated tests finish). Every few months, someone will push something to staging that does not pass the whole tests and builds. In that case the machinery stops before pushing anything to master, and staging needs to be cleaned up. This is not done with reverts but by resetting the branch appropriately in spite of it being a public branch. That's because people are expected not to maintain their personal versions of the "staging" branch from which dropped changes could be reintroduced. -- David Kastrup