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:13:25 +0200 Message-ID: <876134favu.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442824011 1523 80.91.229.3 (21 Sep 2015 08:26:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 08:26:51 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 10:26:50 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 1ZdwQy-0007xv-Lw for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 10:26:48 +0200 Original-Received: from localhost ([::1]:56684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwQy-0007ow-9i for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 04:26:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwE3-0000v6-Tc for emacs-devel@gnu.org; Mon, 21 Sep 2015 04:13:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdwE2-0001W1-Mc for emacs-devel@gnu.org; Mon, 21 Sep 2015 04:13:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33507) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdwE2-0001Vv-Io; Mon, 21 Sep 2015 04:13:26 -0400 Original-Received: from localhost ([127.0.0.1]:47324 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZdwE1-0003Y0-Lq; Mon, 21 Sep 2015 04:13:25 -0400 Original-Received: by lola (Postfix, from userid 1000) id 2C74ADF40C; Mon, 21 Sep 2015 10:13:25 +0200 (CEST) In-Reply-To: <83k2rknr2c.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 10:56:43 +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:190178 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: Dmitry Gutov , monnier@iro.umontreal.ca, >> emacs-devel@gnu.org >> Date: Mon, 21 Sep 2015 09:25:33 +0200 >> >> > 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. > > 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. Why don't we want commits breaking builds/regtests to reach master? For one thing, everything stops working for every developer, even people working on entirely different parts of LilyPond. If the catastrophe stays confined to staging, people can still work on their personal branches and repositories based on current master confidently. They have to wait until staging gets sorted out before they can _push_ again, but their own work is not disrupted. Apart from the temporary nuisance (for which the difference between rewind/revert in staging does not really count: either fix will arrive once it is made), "git bisect" is an important tool for finding problems in history. If parts of the master history do not even compile, that's a total nuisance for figuring out when something started to go wrong. So if our testing procedure gives us equal opportunity to revert or undo a commit that causes the build to fail, choosing the undo means that the resulting history is more useful for future detective work. It also makes less noise for things like "git blame". -- David Kastrup