emacs-devel
[Top][All Lists]
Advanced

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

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


From: Bastian Beischer
Subject: Re: RCS, again: another removed functionality: undo last-checkin
Date: Mon, 21 Sep 2015 12:21:57 +0200

Dear all,

I'm not an emacs developer but I'd like to jump in:

As you may know, in git, when a commit is made it consists of these things:

- A complete of snapshot of the file structure of the entire repository and all file contents
- The commit message, commit time + author time, commiting person
- The SHA1 identifier of the previous commit(s) (there can be multiple in case of a merge commit)

All of these things enter into the SHA1 identifier of the commit! git has the tools to change any of the above a posteriori, but it's vital to understand that any such modification, even if it's just a typo in the commit message will modify the SHA1 of the commit. The old commit with it's identifier still exists, but it's 'dangling' i.e. it's typically not part of the local branch you are working in any more.

Any references to the old identifier of the commit become invalid at that point!

As long as any such discarded commit was not pushed to a public repository, it's generally considered fine to do these modifications to your liking.

However, once a commit is pushed out to a public place the situation changes. People may be using the old ID to refer to that specific commit, whether you know it or not.

Then, whether you want to allow 'rewriting history' depends entirely on the conventions in your project - there's no general rule. In emacs you may say it's OK, even recommened, to modify the staging branch a posteriori in case a mistake was made. Therefore, it's in general impossible to do the right thing without knowing the project policy.

In case rewriting history is not possible or wanted, git revert is there to help you: It simply creates a new commit which applies the reverse patch with an appropriate commit messate, that's all.

I urge you to read these:

- http://git-scm.com/book/en/v2/Git-Internals-Git-References
- man git rebase (section "RECOVERING FROM UPSTREAM REBASE")
- man git tag (section "DISCUSSION - On Re-tagging")

Best
Bastian


On Mon, Sep 21, 2015 at 11:42 AM, Eli Zaretskii <address@hidden> wrote:
> From: David Kastrup <address@hidden>
> Cc: address@hiddenaddress@hiddenaddress@hidden
> 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?

> > 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
> problem.
>
> 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?




--
Bastian Beischer
RWTH Aachen University of Technology

@RWTH Aachen
Office: 28 C 203
Phone: +49-241-80-27205
E-mail: address@hidden
Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen

@CERN
Office: Bdg 32-4-B12
Phone: +41-22-76-75750
E-mail: address@hidden
Address: CERN, CH-1211 Geneve 23

reply via email to

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