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

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> 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?

> > 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.

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?