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