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 12:18:56 +0200 Message-ID: <87fv28dqi7.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> <87wpvkdvo8.fsf@fencepost.gnu.org> <83eghsnp5y.fsf@gnu.org> <87si68du8h.fsf@fencepost.gnu.org> <83bncwnm67.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442830758 9814 80.91.229.3 (21 Sep 2015 10:19:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 10:19:18 +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 12:19:17 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 1ZdyBk-0000i7-JN for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 12:19:12 +0200 Original-Received: from localhost ([::1]:57318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyBk-0001Y5-18 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 06:19:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyBX-0001Xo-0l for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:19:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdyBW-0004Ky-1R for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:18:59 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyBV-0004Ko-Ul; Mon, 21 Sep 2015 06:18:57 -0400 Original-Received: from localhost ([127.0.0.1]:49363 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZdyBU-000241-SV; Mon, 21 Sep 2015 06:18:57 -0400 Original-Received: by lola (Postfix, from userid 1000) id 752CEDF49C; Mon, 21 Sep 2015 12:18:56 +0200 (CEST) In-Reply-To: <83bncwnm67.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 21 Sep 2015 12:42:24 +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:190185 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru >> Date: Mon, 21 Sep 2015 10:58:22 +0200 >> >> >> > 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. >> > >> > Fix how? >> >> Remove the bad commit from the commit history. That's what we are >> talking about the whole time. >> >> > This discussion is about the meaning of "rollback" for Git. So what >> > I'm trying to figure out is whether there's some Git command other >> > than "revert" that the user who pushed a bad commit to "staged" should >> > perform to fix "staging". >> >> git reset --hard HEAD~1 in the simplest case. Or git rebase -i with a >> selective removal of commits. > > Followed by a push, I presume? IOW, the 'staging" branch permits > non-FF pushes? That would be the ideal case (set up via repository setting and a hook that selectively allows some branches to have non-FF pushes and some not). Savannah is not set up this way, so you just delete the branch and push a new one. >> Git's own development tree has "next", another branch which is >> frequently being reset rather than have anything reverted in it. >> Other projects have similar "tryout" branches. When you are using >> branches for proposing patches (like the review tool Gerrit does), >> you are supposed to _amend_ your proposals so that they look like >> they've been done correctly right from the start, rather than adding >> fixes on top. Again, this is rollback territory (or more frequently, >> git rebase -i territory). It is only both public and non-ephemeral >> branches which should not see history changes. > > So I guess we will have to provide a way for the user to tell VC which > branch is of the "revert" type and which is of the "reset" type? I don't think that it's the job of VC to make the user follow some policy it tries guessing. It's the user who needs to specify whether he wants a revert or a reset. I may perfectly well place a revert in the staging branch when the original commit is already in master. But VC has no business snooping around in other branches in order to do some DWIM stuff depending on project-local policies. -- David Kastrup