From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bastian Beischer Newsgroups: gmane.emacs.devel Subject: Re: RCS, again: another removed functionality: undo last-checkin Date: Mon, 21 Sep 2015 12:21:57 +0200 Message-ID: References: <87oagx6tzz.fsf@mat.ucm.es> <55FF4026.2050004@yandex.ru> <83si68nu4i.fsf@gnu.org> <87eghsfd3m.fsf@fencepost.gnu.org> <83k2rknr2c.fsf@gnu.org> <876134favu.fsf@fencepost.gnu.org> <83fv28nq58.fsf@gnu.org> <87wpvkdvo8.fsf@fencepost.gnu.org> <83eghsnp5y.fsf@gnu.org> <87si68du8h.fsf@fencepost.gnu.org> <83bncwnm67.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1130cdca4f833705203f40d6 X-Trace: ger.gmane.org 1442830967 13285 80.91.229.3 (21 Sep 2015 10:22:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 10:22:47 +0000 (UTC) Cc: David Kastrup , Emacs-Devel , monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 21 12:22:42 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdyF7-00059b-U0 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 12:22:42 +0200 Original-Received: from localhost ([::1]:57328 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyF7-0002Lb-71 for ged-emacs-devel@m.gmane.org; Mon, 21 Sep 2015 06:22:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyEY-0002FK-Nm for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:22:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZdyEV-0006a0-In for emacs-devel@gnu.org; Mon, 21 Sep 2015 06:22:06 -0400 Original-Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:35080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZdyEQ-0006WN-M6; Mon, 21 Sep 2015 06:21:58 -0400 Original-Received: by wicge5 with SMTP id ge5so108894716wic.0; Mon, 21 Sep 2015 03:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DvWipVD6k1WiqvLAcIXybyLI3BATcFN49fInter9XJw=; b=IM7uN7j6jrQuJPl1sBRu9e1v7Afi0ndRCFmphVdxhBmnL0zArNl0vcrjSjnD70VTpM K5CU2pz4vlFplCpBHayUpCGtDUIs3A1/FJ78Yl99I8846RNNiF9k3eLKDcCh+YC/adYe 0ojpFzzfPoUJWiImxaG5uGAx93RpQic1ROKaYbM4QbADs61Qzyz2q/LK3HgP1B/w06TZ U8uGYFX19U2XKgzXTxTlR6X+kMF4aZCWfcVrSUjrDQqbNaFv5y+nZphy5wziD8bIv3I0 1dU8eHH9KbVIW6jOs3MhsAiwmxDiuoS7bXVnDp5iGVlxN/X5ZjqurJ3CKStjeXAQYlsE dVtw== X-Received: by 10.194.117.70 with SMTP id kc6mr9364638wjb.13.1442830917532; Mon, 21 Sep 2015 03:21:57 -0700 (PDT) Original-Received: by 10.27.153.1 with HTTP; Mon, 21 Sep 2015 03:21:57 -0700 (PDT) In-Reply-To: <83bncwnm67.fsf@gnu.org> X-Google-Sender-Auth: ZUmM-JZnjJNxfxIkUlIgBr5mjBk X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190187 Archived-At: --001a1130cdca4f833705203f40d6 Content-Type: text/plain; charset=UTF-8 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 wrote: > > From: David Kastrup > > 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 --001a1130cdca4f833705203f40d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

I'm not an emacs develope= r 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 reposit= ory and all file contents
- The commit message, commit time + aut= hor time, commiting person
- The SHA1 identifier of the previous = commit(s) (there can be multiple in case of a merge commit)

All of t= hese 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 mess= age will modify the SHA1 of the commit. The old commit with it's identi= fier 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 a= t that point!

As long as any such discarded commit was not pushed to= a public repository, it's generally considered fine to do these modifi= cations 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 entir= ely on the conventions in your project - there's no general rule. In em= acs 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 imp= ossible to do the right thing without knowing the project policy.

In case rewriting history is not possible or wanted, git re= vert 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:

- h= ttp://git-scm.com/book/en/v2/Git-Internals-Git-References
- man git = rebase (section "RECOVERING FROM= UPSTREAM REBASE")
- man git tag (section "DISCUSSION -=C2= =A0On Re-tagging")=

Best
Bastian
=


On Mon, S= ep 21, 2015 at 11:42 AM, Eli Zaretskii <eliz@gnu.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> From: David Kastrup <= ;dak@gnu.org>
> Cc: emacs-devel@gnu.org,=C2= =A0 monnier@iro.umontreal.ca,=C2=A0 dgutov@yandex.ru
> Date: Mon, 21 Sep 2015 10:58:22 +0200
>
> >> > OK, but what would you do instead, then, in the case whe= re the commit
> >> > is on "staged", but not yet on master?
> >>
> >> You fix staging.
> >
> > Fix how?
>
> Remove the bad commit from the commit history.=C2=A0 That's what w= e are
> talking about the whole time.
>
> > This discussion is about the meaning of "rollback" for = Git.=C2=A0 So what
> > I'm trying to figure out is whether there's some Git comm= and 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.=C2=A0 Or git rebase -i w= ith a
> selective removal of commits.

Followed by a push, I presume?=C2=A0 IOW, the 'staging" bra= nch permits
non-FF pushes?

> > then "revert" is still a good interpretation of "r= ollback", even with
> > the workflow you describe, because in that workflow the user simp= ly
> > 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 wh= ich is
> frequently being reset rather than have anything reverted in it.=C2=A0= Other
> projects have similar "tryout" branches.=C2=A0 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.<= br> > Again, this is rollback territory (or more frequently, git rebase -i > territory).=C2=A0 It is only both public and non-ephemeral branches wh= ich
> should not see history changes.

So I guess we will have to provide a way for the user to tell VC whi= ch
branch is of the "revert" type and which is of the "reset&qu= ot; type?




--
Bastian Beischer
RWTH Aachen University of Technolo= gy

@RWTH Aachen
Office: 28 C 203
Phone: +49-241-80-27205
E-= mail: b= eischer@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
--001a1130cdca4f833705203f40d6--