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 10:27:19 +0200 Message-ID: <87wpvkdvo8.fsf@fencepost.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> <876134favu.fsf@fencepost.gnu.org> <83fv28nq58.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442824119 3178 80.91.229.3 (21 Sep 2015 08:28:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 08:28:39 +0000 (UTC) Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 10:28:34 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 1ZdwSf-0001lF-52 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 10:28:33 +0200 Original-Received: from localhost ([::1]:56703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwSe-0001md-Nd for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 04:28:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwRW-0000Bg-Gl for emacs-devel@gnu.org; Mon, 21 Sep 2015 04:27:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdwRV-0007j3-Ly for emacs-devel@gnu.org; Mon, 21 Sep 2015 04:27:22 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:34543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwRV-0007ix-JE; Mon, 21 Sep 2015 04:27:21 -0400 Original-Received: from localhost ([127.0.0.1]:47577 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZdwRU-00051V-9U; Mon, 21 Sep 2015 04:27:20 -0400 Original-Received: by lola (Postfix, from userid 1000) id C714FDF2A1; Mon, 21 Sep 2015 10:27:19 +0200 (CEST) In-Reply-To: <83fv28nq58.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 11:16:35 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.10 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:190179 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Mon, 21 Sep 2015 10:13:25 +0200 >> >> > Thanks, but would this mean that "git revert" for a commit pushed to >> > the "staging" branch would be wrong? If so, can you explain why? >> >> It depends on whether the commit has moved to master already. If it >> has, revert is the only option. If you noticed a mistake and want to >> stop the commit from reaching master, you have to act fast enough that >> the automated process will not make it progress into master. If the >> commit has been stopped by the automated process, you definitely do not >> want to add a revert on top of it to staging and have the combined >> commit+revert reach master. > > OK, but what would you do instead, then, in the case where the commit > is on "staged", but not yet on master? You fix staging. Once the automated process finishes, it checks the main repository and finds that the state of staging no longer contains the commit it tested. So it does not push to master (it does send out a diagnostic Email). The next time it runs, it picks up the fixed state of staging and will hopefully finish. At one point of time, our automated procedure did not do this "is my tested commit still in staging" check before pushing to master. That was a lot more annoying: you noticed a problem, fixed it, and about an hour later the unfixed state (which already had made it into the testing procedure) still appeared in master, deadlocking the machinery because now staging and master were out of synch. This additional test right before pushing to master closed that time window: once you successfully reset staging in the repository, you are safe from the unfixed state getting pushed. -- David Kastrup