Re: RCS, again: another removed functionality: undo last-checkin

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru
>> Date: Mon, 21 Sep 2015 10:27:19 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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.

> If there's nothing to be done locally,

With Git, you do everything locally first.  While it is possible to do
something like

git push origin +origin/staging~1:staging

and remove the top commit from the staging repository even without
involving the current tree, such repository-only operations are pretty
solidly outside of the reign of VC.

> then "revert" is still a good interpretation of "rollback", even with
> the workflow you describe, because in that workflow the user simply
> should not invoke any rollbacks locally.

But the usual thing is to "rollback", namely establish the _commit_
state from before the bad commit, when encountering a staging-only
problem.

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.

-- 
David Kastrup