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: dgutov@yandex.ru,  monnier@iro.umontreal.ca,  emacs-devel@gnu.org
>> Date: Mon, 21 Sep 2015 10:13:25 +0200
>> 
>> > Thanks, but would this mean that "git revert" for a commit pushed to
>> > the "staging" branch would be wrong?  If so, can you explain why?
>> 
>> It depends on whether the commit has moved to master already.  If it
>> has, revert is the only option.  If you noticed a mistake and want to
>> stop the commit from reaching master, you have to act fast enough that
>> the automated process will not make it progress into master.  If the
>> commit has been stopped by the automated process, you definitely do not
>> want to add a revert on top of it to staging and have the combined
>> commit+revert reach master.
>
> 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.  Once the automated process finishes, it checks the
main repository and finds that the state of staging no longer contains
the commit it tested.  So it does not push to master (it does send out a
diagnostic Email).  The next time it runs, it picks up the fixed state
of staging and will hopefully finish.

At one point of time, our automated procedure did not do this "is my
tested commit still in staging" check before pushing to master.  That
was a lot more annoying: you noticed a problem, fixed it, and about an
hour later the unfixed state (which already had made it into the testing
procedure) still appeared in master, deadlocking the machinery because
now staging and master were out of synch.

This additional test right before pushing to master closed that time
window: once you successfully reset staging in the repository, you are
safe from the unfixed state getting pushed.

-- 
David Kastrup