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

[Bastian Beischer <bastian.beischer@rwth-aachen.de>]

[-- Attachment #1: Type: text/plain, Size: 4430 bytes --]

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 <eliz@gnu.org> wrote:

> > 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?
>
> > > 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: beischer@physik.rwth-aachen.de
Address: I. Physikalisches Institut B, Sommerfeldstr. 14, D-52074 Aachen

@CERN
Office: Bdg 32-4-B12
Phone: +41-22-76-75750
E-mail: bastian.beischer@cern.ch
Address: CERN, CH-1211 Geneve 23

[-- Attachment #2: Type: text/html, Size: 6765 bytes --]