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

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > Yes, it does.  From the description of "cvs admin":

But IIRC cvs admin requires shell access to the repository host: you
can't use it from a client machine.

 > So is "cvs -o".  The CVS manual says that much.  Why should Git be
 > different?  A careful user won't invoke this command unless they know
 > what they are doing, right?

A user should not be able to invoke this command at all.

 > > 'git revert', by itself, doesn't affect the remote either.
 > 
 > Indeed, so what is the reason not to use it as "rollback"?

In git, "revert" has the wrong semantics; it adds a commit rather than
removing one.  This would surely confuse anybody who knows a little
bit about databases.

 > I agree.  But the original issue was whether a "rollback" should
 > invoke "git reset --hard", "git revert", or sometimes one and
 > sometimes the other.  The issue never was about adding a "push" to
 > that.

The problem is that users don't push commits.  They push branches.
That resets the ref on the remote end, which will confuse all derived
branches that include the rolled-back commit, even if you don't get
the usual rebase lossage.

My personal take is that `vc-rollback' should do "git reset" (no
--hard!), "hg strip", etc as available on the theory that "rollback"
refers to an in-progress database operation, not the users' edits in
the workspace.  If the user really wants that effect, they can fullow
up with a force-checkout.

If you do implement it as "git reset --hard", it had better have a
warning prompt like, "If you do this, you will lose all work involved
in this commit, in the repo and in your workspace.  Proceed?"