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

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ Sending in private, it's only for information.  ]

Well, didn't work apparently.

>> LilyPond works with a "staging" branch and a "master" branch.  "master"
>> only moves forward: once a commit is in there, it stays.  If its effects
>> are to be annulled, it is reverted.  Nobody pushes to master though.
>> Any changes are instead pushed to staging.  An automated task picks up
>
> Sounds like an attractive organization.
>
> One question, tho: how do you deal with (aka "synchronize") concurrent
> "push" to the staging branch, if you allow the staging branch to be
> "forced" (either via non-FF, or via remove+push)?

Forcing becomes necessary only in extraordinary circumstances.  The
person receiving the failure notices from the automated processes will
likely ask around and then fix the stuff.

In the situation where a committer discovers a blunder himself and fixes
it, there is a non-zero chance that he'll overwrite changes others
pushed after his faulty commit.

In practice, it's mostly myself doing the fixing after either I or
somebody else messed up.

Most are encouraged to
a) rebase on master
b) push to staging (unforced)
c) when non-ff failure, wait an hour or two, fetch and repeat

That's easiest and means you never have to back out changes but it means
arbitrary waiting times.  If you know what you are doing, you can also

a) git rebase origin feature_branch
b) git rebase origin/staging HEAD~0 (detaches HEAD from feature_branch)
c) git push origin HEAD:staging
d) git checkout feature_branch (returns to rebase on master)
e) push fail?  wait an hour, git fetch, restart from top

That way the rebase on staging in step b) does not permanently leave
commits in feature_branch.  Usually it's easiest if only one set of
changes at a time is placed in staging.

The basic premise here is that when something gets messed up, the
automated procedures reliably stop doing anything until somebody with a
reasonable amount of expertise has fixed the situation manually.  In the
meantime, master stays in useful state and work based on it can
continue.  The complication is rarely needed, but every month or two it
saves people from fingerpointing and tension because master locked up.
As an additional boon, the expert fixing the situation feels smug and in
control and is less likely to engage in heated exchanges.

-- 
David Kastrup