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 15:59:29 +0200 Message-ID: <8737y7euv2.fsf@fencepost.gnu.org> References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442844063 29120 80.91.229.3 (21 Sep 2015 14:01:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 14:01:03 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 16:01:00 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 1Ze1eN-0005fI-Sv for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 16:01:00 +0200 Original-Received: from localhost ([::1]:58623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ze1eN-0002im-DQ for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 10:00:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ze1dl-0002an-Os for emacs-devel@gnu.org; Mon, 21 Sep 2015 10:00:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ze1dk-0005IA-9g for emacs-devel@gnu.org; Mon, 21 Sep 2015 10:00:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ze1dk-0005I4-7Z; Mon, 21 Sep 2015 10:00:20 -0400 Original-Received: from localhost ([127.0.0.1]:53522 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Ze1dj-00010s-9B; Mon, 21 Sep 2015 10:00:19 -0400 Original-Received: by lola (Postfix, from userid 1000) id 8A8AADF40C; Mon, 21 Sep 2015 15:59:29 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Mon, 21 Sep 2015 09:13:02 -0400") 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:190191 Archived-At: Stefan Monnier writes: > [ Sending in private, it's only for information. ] Well, didn't work apparently. >> 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 > > Sounds like an attractive organization. > > One question, tho: how do you deal with (aka "synchronize") concurrent > "push" to the staging branch, if you allow the staging branch to be > "forced" (either via non-FF, or via remove+push)? Forcing becomes necessary only in extraordinary circumstances. The person receiving the failure notices from the automated processes will likely ask around and then fix the stuff. In the situation where a committer discovers a blunder himself and fixes it, there is a non-zero chance that he'll overwrite changes others pushed after his faulty commit. In practice, it's mostly myself doing the fixing after either I or somebody else messed up. Most are encouraged to a) rebase on master b) push to staging (unforced) c) when non-ff failure, wait an hour or two, fetch and repeat That's easiest and means you never have to back out changes but it means arbitrary waiting times. If you know what you are doing, you can also a) git rebase origin feature_branch b) git rebase origin/staging HEAD~0 (detaches HEAD from feature_branch) c) git push origin HEAD:staging d) git checkout feature_branch (returns to rebase on master) e) push fail? wait an hour, git fetch, restart from top That way the rebase on staging in step b) does not permanently leave commits in feature_branch. Usually it's easiest if only one set of changes at a time is placed in staging. The basic premise here is that when something gets messed up, the automated procedures reliably stop doing anything until somebody with a reasonable amount of expertise has fixed the situation manually. In the meantime, master stays in useful state and work based on it can continue. The complication is rarely needed, but every month or two it saves people from fingerpointing and tension because master locked up. As an additional boon, the expert fixing the situation feels smug and in control and is less likely to engage in heated exchanges. -- David Kastrup