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: Mon, 21 Sep 2015 10:56:43 +0300 Message-ID: <83k2rknr2c.fsf@gnu.org> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442822225 4965 80.91.229.3 (21 Sep 2015 07:57:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 07:57:05 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 09:56:56 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 1Zdvy3-0002oX-TK for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 09:56:56 +0200 Original-Received: from localhost ([::1]:56434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdvy3-00085Y-D4 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 03:56:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdvy0-00085Q-Hc for emacs-devel@gnu.org; Mon, 21 Sep 2015 03:56:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zdvxz-0002D0-IS for emacs-devel@gnu.org; Mon, 21 Sep 2015 03:56:52 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:51012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zdvxv-0002C8-PA; Mon, 21 Sep 2015 03:56:47 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NV000A00OIN6300@mtaout27.012.net.il>; Mon, 21 Sep 2015 10:52:58 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV00006MOK9E2A0@mtaout27.012.net.il>; Mon, 21 Sep 2015 10:52:58 +0300 (IDT) In-reply-to: <87eghsfd3m.fsf@fencepost.gnu.org> 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.183 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:190176 Archived-At: > 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?