[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: RCS, again: another removed functionality: undo last-checkin
Date: Mon, 21 Sep 2015 10:58:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Mon, 21 Sep 2015 10:27:19 +0200
>> Eli Zaretskii <address@hidden> writes:
>> > 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.

> If there's nothing to be done locally,

With Git, you do everything locally first.  While it is possible to do
something like

git push origin +origin/staging~1:staging

and remove the top commit from the staging repository even without
involving the current tree, such repository-only operations are pretty
solidly outside of the reign of VC.

> 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

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.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]