You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Stamatis Zampetakis <za...@gmail.com> on 2022/03/09 10:08:30 UTC
Broken history after force pushing to master
Hi all,
Something happened during the generation of the 1.30.0 release candidate
and the git history is somewhat broken.
If you use the GitHub repo and you try to pull (DON'T DO IT NOW) changes
from master to update your local copy you will see that a merge commit is
necessary which is not normal.
Moreover, if you check the JIRAs resolved in this release (e.g.,
CALCITE-4991 [1]) you will notice that the comment [2] which indicates the
commit resolving the issue does not belong to any repository.
From the above it seems there has been a force push to master. Looking at
the recent commits [3], I see something like a big rebase but not sure how
we ended up with this situation and why it was necessary.
Going forward, I think the first step is to understand what happened so
that we avoid this reappearing in the future and the second step is to
restore the master branch (and others if affected) to its previous state
from someone's valid local copy; probably this will necessitate another
force-push.
I am not doing anything for now till we agree on how we want to address
this issue.
Best,
Stamatis
[1] https://issues.apache.org/jira/browse/CALCITE-4991
[2]
https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
[3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
Re: Broken history after force pushing to master
Posted by Fan Liya <li...@gmail.com>.
Hi Julian,
Thanks a lot for your feedback. I will start a separate thread to discuss
the related problems when things are done, to avoid similar problems in the
future.
Best,
Liya Fan
Julian Hyde <jh...@gmail.com> 于2022年3月10日周四 08:30写道：
> Yes, the ‘git rebase’ command works in mysterious ways. If it sees commits
> that have the same content it will ignore them, even if they have different
> hashes. Since you want to preserve the hashes in the master branch, the
> direction that you rebase (e.g. from master to site, versus from site to
> master) is crucial.
>
> As RM, you occasionally have to force-push. But force-pushes can be scary.
> It would be nice if there were some guidelines for when force-push is
> necessary, and when it is not going to do much damage (e.g. is only going
> to change 1 commit).
>
> Julian
>
>
> > On Mar 9, 2022, at 4:19 PM, Fan Liya <li...@gmail.com> wrote:
> >
> > Hi Ruben and Stamatis,
> >
> > Thanks a lot for your kind help. I should have sent an email asking for
> > help when I encountered the problem.
> > I must be careful in the future to never repeat such mistake again.
> >
> > In step 2, I found the following commits in site branch but not in master
> > branch (through git log master..site):
> >
> > commit d1324718fae633584a6c5f8e8f6238a0f851cbac
> > Author: Ruben Quesada Lopez <ru...@gmail.com>
> > Date: Sat Jan 29 19:04:14 2022 +0000
> >
> > Site: update PMC Chair
> >
> > commit fabef057c536d56e10530b399543077abad03a24
> > Author: Jing Zhang <be...@gmail.com>
> > Date: Thu Jan 27 17:01:14 2022 +0800
> >
> > Site: Add external resources section in the community page
> >
> > Close apache/calcite#2703
> >
> > commit 48f4bf8596ebfa0f7460ce9358d30028f268cb8e
> > Author: Eugen Stan <eu...@netdava.com>
> > Date: Fri Jan 28 12:02:09 2022 +0200
> >
> > Site: Add "calcite-clj - Use Calcite with Clojure" in talks section
> >
> > Close apache/calcite#2704
> >
> > commit d088cde8d74b9b9b0b157c2f5efe83fcedc6ffef
> > Author: Alessandro Solimando <al...@gmail.com>
> > Date: Mon Jan 10 11:48:29 2022 +0100
> >
> > Site: Add Alessandro Solimando as committer
> >
> > commit 664c4d3f9b0ec03071df6fef44b32169a275ea49
> > Author: mans2singh <ma...@yahoo.com>
> > Date: Wed Jan 5 19:41:56 2022 -0500
> >
> > Site: Fix typo in howto.md
> >
> > commit dd34953aa0b5af13e7e7fccd75b2f2e8fe9c8edd
> > Author: nobigo <no...@gmail.com>
> > Date: Fri Dec 31 21:28:20 2021 +0800
> >
> > Site: Change the javadoc title to Apache Calcite API
> >
> > commit d29aa09321ab14bd824e5465ddcfae8d16604134
> > Author: Guiyanakuang <gu...@gmail.com>
> > Date: Wed Jan 5 10:12:03 2022 +0800
> >
> > Site: For tables that display results, center the content horizontally
> >
> > Close apache/calcite#2632
> >
> > commit da4fc3be015977fb02bf021583a06a5f58278b66
> > Author: Guiyanakuang <gu...@gmail.com>
> > Date: Fri Dec 10 11:27:59 2021 +0800
> >
> > Site: Add syntax highlighting to SQL statements
> >
> > Close apache/calcite#2632
> >
> > commit cee9f670818116387810c5f89035975aa2694658
> > Author: Guiyanakuang <gu...@gmail.com>
> > Date: Sun Dec 5 10:58:32 2021 +0800
> >
> > Site: Improve HTML tables display & update CSV tutorial
> >
> > 1. Allow code pre-wrap in tables.
> > 2. Display horizontal scrollbar in tables when content is too large
> > and cannot be wrapped.
> > 3. Update CSV tutorial example based on current code.
> >
> > Close apache/calcite#2632
> >
> > Later, I found that these changes were also in the master branch (with
> > different commit hashes). However, since they entered the master branch
> in
> > a different order, they got different git commit hashes, and git
> recognized
> > them as different commits. So my operations above in effect changed the
> > order of some commits (and also their commit hashes).
> >
> > Stamatis, if you will help restore the master branch, I think I can help
> > verify the operation, because I have a local backup.
> >
> > When things are done, I think I will start another thread to discuss the
> > problem, to avoid such things happening again in the future.
> >
> > Thanks again for your kind help.
> >
> > Best,
> > Liya Fan
> >
> >
> >
> > Julian Hyde <jh...@gmail.com> 于2022年3月10日周四 08:00写道：
> >
> >> That sounds good. I concur that "[CALCITE-5019] Avoid multiple scans
> when
> >> table is ProjectableFilterableTable and projections and filters act on
> >> different columns” is the last good commit and that its hash should be
> >> dcbc493bf699d961427952c5efc047b76d859096.
> >>
> >> Go ahead when you’re ready.
> >>
> >> Optionally, when you’re done with that, perform the steps to get the
> >> ‘site' branch in sync with the ‘master' branch. That will make it easier
> >> for us to get this release done without any further mishaps.
> >>
> >> Julian
> >>
> >>
> >>> On Mar 9, 2022, at 1:00 PM, Stamatis Zampetakis <za...@gmail.com>
> >> wrote:
> >>>
> >>> It's not the first time that we have had small problems with history so
> >> no
> >>> worries.
> >>> Thankfully with the help of commit@calcite list we can always find a
> >> way to
> >>> fix things as long as we identify the problem soon enough.
> >>>
> >>> According to the change log [1] the last commit before force pushing
> was
> >>> (dcbc493), which corresponds to CALCITE-5019.
> >>>
> >>> * -- * -- B -- O -- O -- O (dcbc493)
> >>> \
> >>> N -- N -- N refs/heads/master (c3dbf52)
> >>>
> >>> According to [2] the full commit id
> >>> is dcbc493bf699d961427952c5efc047b76d859096.
> >>>
> >>> In order to restore the master branch in the state that it was before
> the
> >>> force-push (before release) I plan to do the following steps:
> >>>
> >>> git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> >>> git checkout dcbc493bf699d961427952c5efc047b76d859096
> >>> git branch -D master
> >>> git switch -c master
> >>> git push origin master -f
> >>>
> >>> I will apply the above sequence in 12h from now to give some time to
> >> others
> >>> to react if necessary.
> >>>
> >>> Obviously this will nuke out any current release candidate so we will
> >> need
> >>> to cancel existing votes and create an RC2.
> >>>
> >>> There has been a force push also to the site branch but doesn't matter
> >> much
> >>> since we can force push master to site after the release is finalized.
> >>>
> >>> Best,
> >>> Stamatis
> >>>
> >>> [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> >>> [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> >>>
> >>>
> >>> On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> >>>
> >>>> Hello Liya,
> >>>>
> >>>> No worries, we all make mistakes.
> >>>> I think the sequence of steps that you describe looks like a plausible
> >>>> explanation for how we get into this situation. Do you know (from step
> >> 2)
> >>>> which commits were in site branch that were not in master?
> >>>> If in the future you (or anybody else) get blocked or experience any
> >>>> problem on a certain step during the release process, do not hesitate
> to
> >>>> send an email to the dev list with subject "[HELP] ..." describing the
> >>>> issue. In my experience, someone from the community will assist
> >> relatively
> >>>> fast.
> >>>>
> >>>> Any git expert with a clear idea on how to restore the master branch?
> >>>>
> >>>> Best,
> >>>> Ruben
> >>>>
> >>>>
> >>>> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I think the broken history was caused by this:
> >>>>>
> >>>>> 1. In document "Making a release candidate [1]", it says "Make sure
> >>>> master
> >>>>> branch and site branch are in sync".
> >>>>> 2. I checked the two branches, and find they have diverged. Some
> >> commits
> >>>> in
> >>>>> the site branch are not in the master branch.
> >>>>> 3. I tried the method given in the document "git reset --hard site",
> >> but
> >>>> it
> >>>>> didn't work.
> >>>>> 3. I tried to cherry-pick the commits to master, but it required
> >>>> resolving
> >>>>> conflicts, because the committing order was not correct.
> >>>>> 4. So I used "git rebase -i" to insert the commits into the "right"
> >> place
> >>>>> of the master branch.
> >>>>> 5. Finally, I pushed the result to the original master branch.
> >>>>>
> >>>>> I think that is the reason for the broken history. Really sorry for
> the
> >>>>> trouble.
> >>>>> If needed, I can restore the original master branch. I have backed up
> >> the
> >>>>> branch.
> >>>>>
> >>>>> Best,
> >>>>> Liya Fan
> >>>>>
> >>>>> [1]
> >>>> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >>>>>
> >>>>> xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> >>>>>
> >>>>>> Hi. Stamatis. I agree we need to address this issue first.
> >>>>>> I find some relative descriptions at end of the email
> >>>>>> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4.
> So
> >>>> it
> >>>>> is
> >>>>>> a force push. Sorry I am not very good at Github job flow. But I
> think
> >>>> it
> >>>>>> describes what happened according to the appearances. So I hope this
> >>>> can
> >>>>>> help.
> >>>>>>
> >>>>>> This update added new revisions after undoing existing revisions.
> That
> >>>> is
> >>>>>> to say, some revisions that were in the old version of the branch
> are
> >>>> not
> >>>>>> in the new version. This situation occurs when a user --force
> pushes a
> >>>>>> change and generates a repository containing something like this: *
> --
> >>>> *
> >>>>> --
> >>>>>> B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
> >>>> You
> >>>>>> should already have received notification emails for all of the O
> >>>>>> revisions, and so the following emails describe only the N revisions
> >>>> from
> >>>>>> the common base, B. Any revisions marked "omit" are not gone; other
> >>>>>> references still refer to them. Any revisions marked "discard" are
> >> gone
> >>>>>> forever. The 41 revisions listed above as "new" are entirely new to
> >>>> this
> >>>>>> repository and will be described in separate emails. The revisions
> >>>> listed
> >>>>>> as "add" were already present in the repository and have only been
> >>>> added
> >>>>> to
> >>>>>> this reference.
> >>>>>>
> >>>>>> Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> Something happened during the generation of the 1.30.0 release
> >>>>> candidate
> >>>>>>> and the git history is somewhat broken.
> >>>>>>>
> >>>>>>> If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> >>>>> changes
> >>>>>>> from master to update your local copy you will see that a merge
> >>>> commit
> >>>>> is
> >>>>>>> necessary which is not normal.
> >>>>>>>
> >>>>>>> Moreover, if you check the JIRAs resolved in this release (e.g.,
> >>>>>>> CALCITE-4991 [1]) you will notice that the comment [2] which
> >>>> indicates
> >>>>>> the
> >>>>>>> commit resolving the issue does not belong to any repository.
> >>>>>>>
> >>>>>>> From the above it seems there has been a force push to master.
> >>>> Looking
> >>>>> at
> >>>>>>> the recent commits [3], I see something like a big rebase but not
> >>>> sure
> >>>>>> how
> >>>>>>> we ended up with this situation and why it was necessary.
> >>>>>>>
> >>>>>>> Going forward, I think the first step is to understand what
> happened
> >>>> so
> >>>>>>> that we avoid this reappearing in the future and the second step is
> >>>> to
> >>>>>>> restore the master branch (and others if affected) to its previous
> >>>>> state
> >>>>>>> from someone's valid local copy; probably this will necessitate
> >>>> another
> >>>>>>> force-push.
> >>>>>>>
> >>>>>>> I am not doing anything for now till we agree on how we want to
> >>>> address
> >>>>>>> this issue.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Stamatis
> >>>>>>>
> >>>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-4991
> >>>>>>> [2]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> >>>>>>> [3]
> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: Broken history after force pushing to master
Posted by Julian Hyde <jh...@gmail.com>.
Yes, the ‘git rebase’ command works in mysterious ways. If it sees commits that have the same content it will ignore them, even if they have different hashes. Since you want to preserve the hashes in the master branch, the direction that you rebase (e.g. from master to site, versus from site to master) is crucial.
As RM, you occasionally have to force-push. But force-pushes can be scary. It would be nice if there were some guidelines for when force-push is necessary, and when it is not going to do much damage (e.g. is only going to change 1 commit).
Julian
> On Mar 9, 2022, at 4:19 PM, Fan Liya <li...@gmail.com> wrote:
>
> Hi Ruben and Stamatis,
>
> Thanks a lot for your kind help. I should have sent an email asking for
> help when I encountered the problem.
> I must be careful in the future to never repeat such mistake again.
>
> In step 2, I found the following commits in site branch but not in master
> branch (through git log master..site):
>
> commit d1324718fae633584a6c5f8e8f6238a0f851cbac
> Author: Ruben Quesada Lopez <ru...@gmail.com>
> Date: Sat Jan 29 19:04:14 2022 +0000
>
> Site: update PMC Chair
>
> commit fabef057c536d56e10530b399543077abad03a24
> Author: Jing Zhang <be...@gmail.com>
> Date: Thu Jan 27 17:01:14 2022 +0800
>
> Site: Add external resources section in the community page
>
> Close apache/calcite#2703
>
> commit 48f4bf8596ebfa0f7460ce9358d30028f268cb8e
> Author: Eugen Stan <eu...@netdava.com>
> Date: Fri Jan 28 12:02:09 2022 +0200
>
> Site: Add "calcite-clj - Use Calcite with Clojure" in talks section
>
> Close apache/calcite#2704
>
> commit d088cde8d74b9b9b0b157c2f5efe83fcedc6ffef
> Author: Alessandro Solimando <al...@gmail.com>
> Date: Mon Jan 10 11:48:29 2022 +0100
>
> Site: Add Alessandro Solimando as committer
>
> commit 664c4d3f9b0ec03071df6fef44b32169a275ea49
> Author: mans2singh <ma...@yahoo.com>
> Date: Wed Jan 5 19:41:56 2022 -0500
>
> Site: Fix typo in howto.md
>
> commit dd34953aa0b5af13e7e7fccd75b2f2e8fe9c8edd
> Author: nobigo <no...@gmail.com>
> Date: Fri Dec 31 21:28:20 2021 +0800
>
> Site: Change the javadoc title to Apache Calcite API
>
> commit d29aa09321ab14bd824e5465ddcfae8d16604134
> Author: Guiyanakuang <gu...@gmail.com>
> Date: Wed Jan 5 10:12:03 2022 +0800
>
> Site: For tables that display results, center the content horizontally
>
> Close apache/calcite#2632
>
> commit da4fc3be015977fb02bf021583a06a5f58278b66
> Author: Guiyanakuang <gu...@gmail.com>
> Date: Fri Dec 10 11:27:59 2021 +0800
>
> Site: Add syntax highlighting to SQL statements
>
> Close apache/calcite#2632
>
> commit cee9f670818116387810c5f89035975aa2694658
> Author: Guiyanakuang <gu...@gmail.com>
> Date: Sun Dec 5 10:58:32 2021 +0800
>
> Site: Improve HTML tables display & update CSV tutorial
>
> 1. Allow code pre-wrap in tables.
> 2. Display horizontal scrollbar in tables when content is too large
> and cannot be wrapped.
> 3. Update CSV tutorial example based on current code.
>
> Close apache/calcite#2632
>
> Later, I found that these changes were also in the master branch (with
> different commit hashes). However, since they entered the master branch in
> a different order, they got different git commit hashes, and git recognized
> them as different commits. So my operations above in effect changed the
> order of some commits (and also their commit hashes).
>
> Stamatis, if you will help restore the master branch, I think I can help
> verify the operation, because I have a local backup.
>
> When things are done, I think I will start another thread to discuss the
> problem, to avoid such things happening again in the future.
>
> Thanks again for your kind help.
>
> Best,
> Liya Fan
>
>
>
> Julian Hyde <jh...@gmail.com> 于2022年3月10日周四 08:00写道：
>
>> That sounds good. I concur that "[CALCITE-5019] Avoid multiple scans when
>> table is ProjectableFilterableTable and projections and filters act on
>> different columns” is the last good commit and that its hash should be
>> dcbc493bf699d961427952c5efc047b76d859096.
>>
>> Go ahead when you’re ready.
>>
>> Optionally, when you’re done with that, perform the steps to get the
>> ‘site' branch in sync with the ‘master' branch. That will make it easier
>> for us to get this release done without any further mishaps.
>>
>> Julian
>>
>>
>>> On Mar 9, 2022, at 1:00 PM, Stamatis Zampetakis <za...@gmail.com>
>> wrote:
>>>
>>> It's not the first time that we have had small problems with history so
>> no
>>> worries.
>>> Thankfully with the help of commit@calcite list we can always find a
>> way to
>>> fix things as long as we identify the problem soon enough.
>>>
>>> According to the change log [1] the last commit before force pushing was
>>> (dcbc493), which corresponds to CALCITE-5019.
>>>
>>> * -- * -- B -- O -- O -- O (dcbc493)
>>> \
>>> N -- N -- N refs/heads/master (c3dbf52)
>>>
>>> According to [2] the full commit id
>>> is dcbc493bf699d961427952c5efc047b76d859096.
>>>
>>> In order to restore the master branch in the state that it was before the
>>> force-push (before release) I plan to do the following steps:
>>>
>>> git fetch origin dcbc493bf699d961427952c5efc047b76d859096
>>> git checkout dcbc493bf699d961427952c5efc047b76d859096
>>> git branch -D master
>>> git switch -c master
>>> git push origin master -f
>>>
>>> I will apply the above sequence in 12h from now to give some time to
>> others
>>> to react if necessary.
>>>
>>> Obviously this will nuke out any current release candidate so we will
>> need
>>> to cancel existing votes and create an RC2.
>>>
>>> There has been a force push also to the site branch but doesn't matter
>> much
>>> since we can force push master to site after the release is finalized.
>>>
>>> Best,
>>> Stamatis
>>>
>>> [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
>>> [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
>>>
>>>
>>> On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
>>>
>>>> Hello Liya,
>>>>
>>>> No worries, we all make mistakes.
>>>> I think the sequence of steps that you describe looks like a plausible
>>>> explanation for how we get into this situation. Do you know (from step
>> 2)
>>>> which commits were in site branch that were not in master?
>>>> If in the future you (or anybody else) get blocked or experience any
>>>> problem on a certain step during the release process, do not hesitate to
>>>> send an email to the dev list with subject "[HELP] ..." describing the
>>>> issue. In my experience, someone from the community will assist
>> relatively
>>>> fast.
>>>>
>>>> Any git expert with a clear idea on how to restore the master branch?
>>>>
>>>> Best,
>>>> Ruben
>>>>
>>>>
>>>> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I think the broken history was caused by this:
>>>>>
>>>>> 1. In document "Making a release candidate [1]", it says "Make sure
>>>> master
>>>>> branch and site branch are in sync".
>>>>> 2. I checked the two branches, and find they have diverged. Some
>> commits
>>>> in
>>>>> the site branch are not in the master branch.
>>>>> 3. I tried the method given in the document "git reset --hard site",
>> but
>>>> it
>>>>> didn't work.
>>>>> 3. I tried to cherry-pick the commits to master, but it required
>>>> resolving
>>>>> conflicts, because the committing order was not correct.
>>>>> 4. So I used "git rebase -i" to insert the commits into the "right"
>> place
>>>>> of the master branch.
>>>>> 5. Finally, I pushed the result to the original master branch.
>>>>>
>>>>> I think that is the reason for the broken history. Really sorry for the
>>>>> trouble.
>>>>> If needed, I can restore the original master branch. I have backed up
>> the
>>>>> branch.
>>>>>
>>>>> Best,
>>>>> Liya Fan
>>>>>
>>>>> [1]
>>>> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>>>>>
>>>>> xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
>>>>>
>>>>>> Hi. Stamatis. I agree we need to address this issue first.
>>>>>> I find some relative descriptions at end of the email
>>>>>> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So
>>>> it
>>>>> is
>>>>>> a force push. Sorry I am not very good at Github job flow. But I think
>>>> it
>>>>>> describes what happened according to the appearances. So I hope this
>>>> can
>>>>>> help.
>>>>>>
>>>>>> This update added new revisions after undoing existing revisions. That
>>>> is
>>>>>> to say, some revisions that were in the old version of the branch are
>>>> not
>>>>>> in the new version. This situation occurs when a user --force pushes a
>>>>>> change and generates a repository containing something like this: * --
>>>> *
>>>>> --
>>>>>> B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
>>>> You
>>>>>> should already have received notification emails for all of the O
>>>>>> revisions, and so the following emails describe only the N revisions
>>>> from
>>>>>> the common base, B. Any revisions marked "omit" are not gone; other
>>>>>> references still refer to them. Any revisions marked "discard" are
>> gone
>>>>>> forever. The 41 revisions listed above as "new" are entirely new to
>>>> this
>>>>>> repository and will be described in separate emails. The revisions
>>>> listed
>>>>>> as "add" were already present in the repository and have only been
>>>> added
>>>>> to
>>>>>> this reference.
>>>>>>
>>>>>> Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Something happened during the generation of the 1.30.0 release
>>>>> candidate
>>>>>>> and the git history is somewhat broken.
>>>>>>>
>>>>>>> If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
>>>>> changes
>>>>>>> from master to update your local copy you will see that a merge
>>>> commit
>>>>> is
>>>>>>> necessary which is not normal.
>>>>>>>
>>>>>>> Moreover, if you check the JIRAs resolved in this release (e.g.,
>>>>>>> CALCITE-4991 [1]) you will notice that the comment [2] which
>>>> indicates
>>>>>> the
>>>>>>> commit resolving the issue does not belong to any repository.
>>>>>>>
>>>>>>> From the above it seems there has been a force push to master.
>>>> Looking
>>>>> at
>>>>>>> the recent commits [3], I see something like a big rebase but not
>>>> sure
>>>>>> how
>>>>>>> we ended up with this situation and why it was necessary.
>>>>>>>
>>>>>>> Going forward, I think the first step is to understand what happened
>>>> so
>>>>>>> that we avoid this reappearing in the future and the second step is
>>>> to
>>>>>>> restore the master branch (and others if affected) to its previous
>>>>> state
>>>>>>> from someone's valid local copy; probably this will necessitate
>>>> another
>>>>>>> force-push.
>>>>>>>
>>>>>>> I am not doing anything for now till we agree on how we want to
>>>> address
>>>>>>> this issue.
>>>>>>>
>>>>>>> Best,
>>>>>>> Stamatis
>>>>>>>
>>>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-4991
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
>>>>>>> [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: Broken history after force pushing to master
Posted by Fan Liya <li...@gmail.com>.
Hi Ruben and Stamatis,
Thanks a lot for your kind help. I should have sent an email asking for
help when I encountered the problem.
I must be careful in the future to never repeat such mistake again.
In step 2, I found the following commits in site branch but not in master
branch (through git log master..site):
commit d1324718fae633584a6c5f8e8f6238a0f851cbac
Author: Ruben Quesada Lopez <ru...@gmail.com>
Date: Sat Jan 29 19:04:14 2022 +0000
Site: update PMC Chair
commit fabef057c536d56e10530b399543077abad03a24
Author: Jing Zhang <be...@gmail.com>
Date: Thu Jan 27 17:01:14 2022 +0800
Site: Add external resources section in the community page
Close apache/calcite#2703
commit 48f4bf8596ebfa0f7460ce9358d30028f268cb8e
Author: Eugen Stan <eu...@netdava.com>
Date: Fri Jan 28 12:02:09 2022 +0200
Site: Add "calcite-clj - Use Calcite with Clojure" in talks section
Close apache/calcite#2704
commit d088cde8d74b9b9b0b157c2f5efe83fcedc6ffef
Author: Alessandro Solimando <al...@gmail.com>
Date: Mon Jan 10 11:48:29 2022 +0100
Site: Add Alessandro Solimando as committer
commit 664c4d3f9b0ec03071df6fef44b32169a275ea49
Author: mans2singh <ma...@yahoo.com>
Date: Wed Jan 5 19:41:56 2022 -0500
Site: Fix typo in howto.md
commit dd34953aa0b5af13e7e7fccd75b2f2e8fe9c8edd
Author: nobigo <no...@gmail.com>
Date: Fri Dec 31 21:28:20 2021 +0800
Site: Change the javadoc title to Apache Calcite API
commit d29aa09321ab14bd824e5465ddcfae8d16604134
Author: Guiyanakuang <gu...@gmail.com>
Date: Wed Jan 5 10:12:03 2022 +0800
Site: For tables that display results, center the content horizontally
Close apache/calcite#2632
commit da4fc3be015977fb02bf021583a06a5f58278b66
Author: Guiyanakuang <gu...@gmail.com>
Date: Fri Dec 10 11:27:59 2021 +0800
Site: Add syntax highlighting to SQL statements
Close apache/calcite#2632
commit cee9f670818116387810c5f89035975aa2694658
Author: Guiyanakuang <gu...@gmail.com>
Date: Sun Dec 5 10:58:32 2021 +0800
Site: Improve HTML tables display & update CSV tutorial
1. Allow code pre-wrap in tables.
2. Display horizontal scrollbar in tables when content is too large
and cannot be wrapped.
3. Update CSV tutorial example based on current code.
Close apache/calcite#2632
Later, I found that these changes were also in the master branch (with
different commit hashes). However, since they entered the master branch in
a different order, they got different git commit hashes, and git recognized
them as different commits. So my operations above in effect changed the
order of some commits (and also their commit hashes).
Stamatis, if you will help restore the master branch, I think I can help
verify the operation, because I have a local backup.
When things are done, I think I will start another thread to discuss the
problem, to avoid such things happening again in the future.
Thanks again for your kind help.
Best,
Liya Fan
Julian Hyde <jh...@gmail.com> 于2022年3月10日周四 08:00写道：
> That sounds good. I concur that "[CALCITE-5019] Avoid multiple scans when
> table is ProjectableFilterableTable and projections and filters act on
> different columns” is the last good commit and that its hash should be
> dcbc493bf699d961427952c5efc047b76d859096.
>
> Go ahead when you’re ready.
>
> Optionally, when you’re done with that, perform the steps to get the
> ‘site' branch in sync with the ‘master' branch. That will make it easier
> for us to get this release done without any further mishaps.
>
> Julian
>
>
> > On Mar 9, 2022, at 1:00 PM, Stamatis Zampetakis <za...@gmail.com>
> wrote:
> >
> > It's not the first time that we have had small problems with history so
> no
> > worries.
> > Thankfully with the help of commit@calcite list we can always find a
> way to
> > fix things as long as we identify the problem soon enough.
> >
> > According to the change log [1] the last commit before force pushing was
> > (dcbc493), which corresponds to CALCITE-5019.
> >
> > * -- * -- B -- O -- O -- O (dcbc493)
> > \
> > N -- N -- N refs/heads/master (c3dbf52)
> >
> > According to [2] the full commit id
> > is dcbc493bf699d961427952c5efc047b76d859096.
> >
> > In order to restore the master branch in the state that it was before the
> > force-push (before release) I plan to do the following steps:
> >
> > git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> > git checkout dcbc493bf699d961427952c5efc047b76d859096
> > git branch -D master
> > git switch -c master
> > git push origin master -f
> >
> > I will apply the above sequence in 12h from now to give some time to
> others
> > to react if necessary.
> >
> > Obviously this will nuke out any current release candidate so we will
> need
> > to cancel existing votes and create an RC2.
> >
> > There has been a force push also to the site branch but doesn't matter
> much
> > since we can force push master to site after the release is finalized.
> >
> > Best,
> > Stamatis
> >
> > [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> >
> >
> > On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> >
> >> Hello Liya,
> >>
> >> No worries, we all make mistakes.
> >> I think the sequence of steps that you describe looks like a plausible
> >> explanation for how we get into this situation. Do you know (from step
> 2)
> >> which commits were in site branch that were not in master?
> >> If in the future you (or anybody else) get blocked or experience any
> >> problem on a certain step during the release process, do not hesitate to
> >> send an email to the dev list with subject "[HELP] ..." describing the
> >> issue. In my experience, someone from the community will assist
> relatively
> >> fast.
> >>
> >> Any git expert with a clear idea on how to restore the master branch?
> >>
> >> Best,
> >> Ruben
> >>
> >>
> >> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I think the broken history was caused by this:
> >>>
> >>> 1. In document "Making a release candidate [1]", it says "Make sure
> >> master
> >>> branch and site branch are in sync".
> >>> 2. I checked the two branches, and find they have diverged. Some
> commits
> >> in
> >>> the site branch are not in the master branch.
> >>> 3. I tried the method given in the document "git reset --hard site",
> but
> >> it
> >>> didn't work.
> >>> 3. I tried to cherry-pick the commits to master, but it required
> >> resolving
> >>> conflicts, because the committing order was not correct.
> >>> 4. So I used "git rebase -i" to insert the commits into the "right"
> place
> >>> of the master branch.
> >>> 5. Finally, I pushed the result to the original master branch.
> >>>
> >>> I think that is the reason for the broken history. Really sorry for the
> >>> trouble.
> >>> If needed, I can restore the original master branch. I have backed up
> the
> >>> branch.
> >>>
> >>> Best,
> >>> Liya Fan
> >>>
> >>> [1]
> >> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >>>
> >>> xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> >>>
> >>>> Hi. Stamatis. I agree we need to address this issue first.
> >>>> I find some relative descriptions at end of the email
> >>>> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So
> >> it
> >>> is
> >>>> a force push. Sorry I am not very good at Github job flow. But I think
> >> it
> >>>> describes what happened according to the appearances. So I hope this
> >> can
> >>>> help.
> >>>>
> >>>> This update added new revisions after undoing existing revisions. That
> >> is
> >>>> to say, some revisions that were in the old version of the branch are
> >> not
> >>>> in the new version. This situation occurs when a user --force pushes a
> >>>> change and generates a repository containing something like this: * --
> >> *
> >>> --
> >>>> B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
> >> You
> >>>> should already have received notification emails for all of the O
> >>>> revisions, and so the following emails describe only the N revisions
> >> from
> >>>> the common base, B. Any revisions marked "omit" are not gone; other
> >>>> references still refer to them. Any revisions marked "discard" are
> gone
> >>>> forever. The 41 revisions listed above as "new" are entirely new to
> >> this
> >>>> repository and will be described in separate emails. The revisions
> >> listed
> >>>> as "add" were already present in the repository and have only been
> >> added
> >>> to
> >>>> this reference.
> >>>>
> >>>> Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Something happened during the generation of the 1.30.0 release
> >>> candidate
> >>>>> and the git history is somewhat broken.
> >>>>>
> >>>>> If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> >>> changes
> >>>>> from master to update your local copy you will see that a merge
> >> commit
> >>> is
> >>>>> necessary which is not normal.
> >>>>>
> >>>>> Moreover, if you check the JIRAs resolved in this release (e.g.,
> >>>>> CALCITE-4991 [1]) you will notice that the comment [2] which
> >> indicates
> >>>> the
> >>>>> commit resolving the issue does not belong to any repository.
> >>>>>
> >>>>> From the above it seems there has been a force push to master.
> >> Looking
> >>> at
> >>>>> the recent commits [3], I see something like a big rebase but not
> >> sure
> >>>> how
> >>>>> we ended up with this situation and why it was necessary.
> >>>>>
> >>>>> Going forward, I think the first step is to understand what happened
> >> so
> >>>>> that we avoid this reappearing in the future and the second step is
> >> to
> >>>>> restore the master branch (and others if affected) to its previous
> >>> state
> >>>>> from someone's valid local copy; probably this will necessitate
> >> another
> >>>>> force-push.
> >>>>>
> >>>>> I am not doing anything for now till we agree on how we want to
> >> address
> >>>>> this issue.
> >>>>>
> >>>>> Best,
> >>>>> Stamatis
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/CALCITE-4991
> >>>>> [2]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> >>>>> [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Broken history after force pushing to master
Posted by Julian Hyde <jh...@gmail.com>.
That sounds good. I concur that "[CALCITE-5019] Avoid multiple scans when table is ProjectableFilterableTable and projections and filters act on different columns” is the last good commit and that its hash should be dcbc493bf699d961427952c5efc047b76d859096.
Go ahead when you’re ready.
Optionally, when you’re done with that, perform the steps to get the ‘site' branch in sync with the ‘master' branch. That will make it easier for us to get this release done without any further mishaps.
Julian
> On Mar 9, 2022, at 1:00 PM, Stamatis Zampetakis <za...@gmail.com> wrote:
>
> It's not the first time that we have had small problems with history so no
> worries.
> Thankfully with the help of commit@calcite list we can always find a way to
> fix things as long as we identify the problem soon enough.
>
> According to the change log [1] the last commit before force pushing was
> (dcbc493), which corresponds to CALCITE-5019.
>
> * -- * -- B -- O -- O -- O (dcbc493)
> \
> N -- N -- N refs/heads/master (c3dbf52)
>
> According to [2] the full commit id
> is dcbc493bf699d961427952c5efc047b76d859096.
>
> In order to restore the master branch in the state that it was before the
> force-push (before release) I plan to do the following steps:
>
> git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> git checkout dcbc493bf699d961427952c5efc047b76d859096
> git branch -D master
> git switch -c master
> git push origin master -f
>
> I will apply the above sequence in 12h from now to give some time to others
> to react if necessary.
>
> Obviously this will nuke out any current release candidate so we will need
> to cancel existing votes and create an RC2.
>
> There has been a force push also to the site branch but doesn't matter much
> since we can force push master to site after the release is finalized.
>
> Best,
> Stamatis
>
> [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
>
>
> On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
>
>> Hello Liya,
>>
>> No worries, we all make mistakes.
>> I think the sequence of steps that you describe looks like a plausible
>> explanation for how we get into this situation. Do you know (from step 2)
>> which commits were in site branch that were not in master?
>> If in the future you (or anybody else) get blocked or experience any
>> problem on a certain step during the release process, do not hesitate to
>> send an email to the dev list with subject "[HELP] ..." describing the
>> issue. In my experience, someone from the community will assist relatively
>> fast.
>>
>> Any git expert with a clear idea on how to restore the master branch?
>>
>> Best,
>> Ruben
>>
>>
>> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I think the broken history was caused by this:
>>>
>>> 1. In document "Making a release candidate [1]", it says "Make sure
>> master
>>> branch and site branch are in sync".
>>> 2. I checked the two branches, and find they have diverged. Some commits
>> in
>>> the site branch are not in the master branch.
>>> 3. I tried the method given in the document "git reset --hard site", but
>> it
>>> didn't work.
>>> 3. I tried to cherry-pick the commits to master, but it required
>> resolving
>>> conflicts, because the committing order was not correct.
>>> 4. So I used "git rebase -i" to insert the commits into the "right" place
>>> of the master branch.
>>> 5. Finally, I pushed the result to the original master branch.
>>>
>>> I think that is the reason for the broken history. Really sorry for the
>>> trouble.
>>> If needed, I can restore the original master branch. I have backed up the
>>> branch.
>>>
>>> Best,
>>> Liya Fan
>>>
>>> [1]
>> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>>>
>>> xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
>>>
>>>> Hi. Stamatis. I agree we need to address this issue first.
>>>> I find some relative descriptions at end of the email
>>>> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So
>> it
>>> is
>>>> a force push. Sorry I am not very good at Github job flow. But I think
>> it
>>>> describes what happened according to the appearances. So I hope this
>> can
>>>> help.
>>>>
>>>> This update added new revisions after undoing existing revisions. That
>> is
>>>> to say, some revisions that were in the old version of the branch are
>> not
>>>> in the new version. This situation occurs when a user --force pushes a
>>>> change and generates a repository containing something like this: * --
>> *
>>> --
>>>> B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
>> You
>>>> should already have received notification emails for all of the O
>>>> revisions, and so the following emails describe only the N revisions
>> from
>>>> the common base, B. Any revisions marked "omit" are not gone; other
>>>> references still refer to them. Any revisions marked "discard" are gone
>>>> forever. The 41 revisions listed above as "new" are entirely new to
>> this
>>>> repository and will be described in separate emails. The revisions
>> listed
>>>> as "add" were already present in the repository and have only been
>> added
>>> to
>>>> this reference.
>>>>
>>>> Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
>>>>
>>>>> Hi all,
>>>>>
>>>>> Something happened during the generation of the 1.30.0 release
>>> candidate
>>>>> and the git history is somewhat broken.
>>>>>
>>>>> If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
>>> changes
>>>>> from master to update your local copy you will see that a merge
>> commit
>>> is
>>>>> necessary which is not normal.
>>>>>
>>>>> Moreover, if you check the JIRAs resolved in this release (e.g.,
>>>>> CALCITE-4991 [1]) you will notice that the comment [2] which
>> indicates
>>>> the
>>>>> commit resolving the issue does not belong to any repository.
>>>>>
>>>>> From the above it seems there has been a force push to master.
>> Looking
>>> at
>>>>> the recent commits [3], I see something like a big rebase but not
>> sure
>>>> how
>>>>> we ended up with this situation and why it was necessary.
>>>>>
>>>>> Going forward, I think the first step is to understand what happened
>> so
>>>>> that we avoid this reappearing in the future and the second step is
>> to
>>>>> restore the master branch (and others if affected) to its previous
>>> state
>>>>> from someone's valid local copy; probably this will necessitate
>> another
>>>>> force-push.
>>>>>
>>>>> I am not doing anything for now till we agree on how we want to
>> address
>>>>> this issue.
>>>>>
>>>>> Best,
>>>>> Stamatis
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/CALCITE-4991
>>>>> [2]
>>>>>
>>>>>
>>>>
>>>
>> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
>>>>> [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
>>>>>
>>>>
>>>
>>
Re: Broken history after force pushing to master
Posted by Fan Liya <li...@gmail.com>.
Hi Ruben,
Thanks a lot for your good comments. They are really helpful. I have added
them to the PR (https://github.com/apache/calcite/pull/2741)
Maybe later we can add more comments to make things clearer.
Best,
Liya Fan
Ruben Q L <ru...@gmail.com> 于2022年3月10日周四 19:11写道：
> Hello,
>
> Thanks everyone for helping with the issue, especially Stamatis for
> carrying out the restore.
> I agree with leaving the possibility of force push into master, since it
> can be convenient in certain (very specific) cases.
>
> Regarding this:
>
> In step 2, I found the following commits in site branch but not in master
> branch (through git log master..site):
> ...
> Later, I found that these changes were also in the master branch (with
> different commit hashes) ...
>
>
> I can understand the confusion considering how the instruction is phrased
> [1]:
> «Make sure master branch and site branch are in sync, i.e. there is no
> commit on site that has not been applied also to master.»
>
> I think it was me who introduced this sentence, it should be clarified to
> avoid the same problem in the future. Maybe by adding something along the
> lines:
> «Make sure master branch and site branch are in sync, i.e. there is no
> commit on site that has not been applied also to master. We are talking
> about the commit content, you need to pay attention to the commit message
> and change, not hash: it is normal to have the same change in site and
> master, but with different hashes.»
>
> We could add this clarification later after the RC process, or we can take
> advantage of the RC PR [2], which already touches the howto.md file (where
> the problematic sentences is located). Liya Fan, as release manager, I
> think it's up to you.
>
> Best,
> Ruben
>
> [1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> [2] https://github.com/apache/calcite/pull/2741
>
>
> On Thu, Mar 10, 2022 at 9:50 AM Fan Liya <li...@gmail.com> wrote:
>
> > Hi Stamatis,
> >
> > Thanks a lot for your effort.
> > I just tested, and the master branch is in consistent state with my local
> > back-up. So I think it has restored to the original state.
> >
> > I have submitted a PR for the release note (
> > https://github.com/apache/calcite/pull/2741).
> > After it gets merged, I will prepare another build (RC2) and restart the
> > voting process.
> >
> > Thanks again for your kind help.
> >
> > Best,
> > Liya Fan
> >
> >
> > Stamatis Zampetakis <za...@gmail.com> 于2022年3月10日周四 17:36写道：
> >
> > > Thanks for the clarifications Liya.
> > >
> > > I restored the master branch to its previous state and aligned master
> and
> > > site.
> > > Now we can proceed with the release. Normally there shouldn't be a need
> > to
> > > force-push again during this release.
> > >
> > > I don't think we want to disable force pushing altogether.
> > > Without force pushing if we accidentally merge things to the repo we
> > > wouldn't have a way to fix this easily.
> > > A trivial example that comes to mind is putting a wrong JIRA id in the
> > > commit message.
> > > Leaving the commit message as is, will not be the end of the world but
> it
> > > can be annoying when in the future people will get redirected to a
> wrong
> > > jira.
> > > Other examples include accidentally introducing merge commits etc.
> > >
> > > Best,
> > > Stamatis
> > >
> > >
> > > On Thu, Mar 10, 2022 at 6:28 AM stanilovsky evgeny <
> > > estanilovskiy@gridgain.com> wrote:
> > >
> > > > Just notice - github allows to disable a force push into master
> branch.
> > > >
> > > > > It's not the first time that we have had small problems with
> history
> > so
> > > > > no
> > > > > worries.
> > > > > Thankfully with the help of commit@calcite list we can always
> find a
> > > > way
> > > > > to
> > > > > fix things as long as we identify the problem soon enough.
> > > > >
> > > > > According to the change log [1] the last commit before force
> pushing
> > > was
> > > > > (dcbc493), which corresponds to CALCITE-5019.
> > > > >
> > > > > * -- * -- B -- O -- O -- O (dcbc493)
> > > > > \
> > > > > N -- N -- N refs/heads/master (c3dbf52)
> > > > >
> > > > > According to [2] the full commit id
> > > > > is dcbc493bf699d961427952c5efc047b76d859096.
> > > > >
> > > > > In order to restore the master branch in the state that it was
> before
> > > the
> > > > > force-push (before release) I plan to do the following steps:
> > > > >
> > > > > git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> > > > > git checkout dcbc493bf699d961427952c5efc047b76d859096
> > > > > git branch -D master
> > > > > git switch -c master
> > > > > git push origin master -f
> > > > >
> > > > > I will apply the above sequence in 12h from now to give some time
> to
> > > > > others
> > > > > to react if necessary.
> > > > >
> > > > > Obviously this will nuke out any current release candidate so we
> will
> > > > > need
> > > > > to cancel existing votes and create an RC2.
> > > > >
> > > > > There has been a force push also to the site branch but doesn't
> > matter
> > > > > much
> > > > > since we can force push master to site after the release is
> > finalized.
> > > > >
> > > > > Best,
> > > > > Stamatis
> > > > >
> > > > > [1]
> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > > > [2]
> https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> > > > >
> > > > >
> > > > > On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com>
> wrote:
> > > > >
> > > > >> Hello Liya,
> > > > >>
> > > > >> No worries, we all make mistakes.
> > > > >> I think the sequence of steps that you describe looks like a
> > plausible
> > > > >> explanation for how we get into this situation. Do you know (from
> > step
> > > > >> 2)
> > > > >> which commits were in site branch that were not in master?
> > > > >> If in the future you (or anybody else) get blocked or experience
> any
> > > > >> problem on a certain step during the release process, do not
> > hesitate
> > > to
> > > > >> send an email to the dev list with subject "[HELP] ..." describing
> > the
> > > > >> issue. In my experience, someone from the community will assist
> > > > >> relatively
> > > > >> fast.
> > > > >>
> > > > >> Any git expert with a clear idea on how to restore the master
> > branch?
> > > > >>
> > > > >> Best,
> > > > >> Ruben
> > > > >>
> > > > >>
> > > > >> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com>
> > wrote:
> > > > >>
> > > > >> > Hi all,
> > > > >> >
> > > > >> > I think the broken history was caused by this:
> > > > >> >
> > > > >> > 1. In document "Making a release candidate [1]", it says "Make
> > sure
> > > > >> master
> > > > >> > branch and site branch are in sync".
> > > > >> > 2. I checked the two branches, and find they have diverged. Some
> > > > >> commits
> > > > >> in
> > > > >> > the site branch are not in the master branch.
> > > > >> > 3. I tried the method given in the document "git reset --hard
> > site",
> > > > >> but
> > > > >> it
> > > > >> > didn't work.
> > > > >> > 3. I tried to cherry-pick the commits to master, but it required
> > > > >> resolving
> > > > >> > conflicts, because the committing order was not correct.
> > > > >> > 4. So I used "git rebase -i" to insert the commits into the
> > "right"
> > > > >> place
> > > > >> > of the master branch.
> > > > >> > 5. Finally, I pushed the result to the original master branch.
> > > > >> >
> > > > >> > I think that is the reason for the broken history. Really sorry
> > for
> > > > >> the
> > > > >> > trouble.
> > > > >> > If needed, I can restore the original master branch. I have
> backed
> > > > up
> > > > >> the
> > > > >> > branch.
> > > > >> >
> > > > >> > Best,
> > > > >> > Liya Fan
> > > > >> >
> > > > >> > [1]
> > > > >>
> > https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> > > > >> >
> > > > >> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> > > > >> >
> > > > >> > > Hi. Stamatis. I agree we need to address this issue first.
> > > > >> > > I find some relative descriptions at end of the email
> > > > >> > >
> > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4.
> > > > So
> > > > >> it
> > > > >> > is
> > > > >> > > a force push. Sorry I am not very good at Github job flow.
> But I
> > > > >> think
> > > > >> it
> > > > >> > > describes what happened according to the appearances. So I
> hope
> > > this
> > > > >> can
> > > > >> > > help.
> > > > >> > >
> > > > >> > > This update added new revisions after undoing existing
> > revisions.
> > > > >> That
> > > > >> is
> > > > >> > > to say, some revisions that were in the old version of the
> > branch
> > > > >> are
> > > > >> not
> > > > >> > > in the new version. This situation occurs when a user --force
> > > > >> pushes a
> > > > >> > > change and generates a repository containing something like
> > this:
> > > > *
> > > > >> --
> > > > >> *
> > > > >> > --
> > > > >> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master
> > > (c3dbf52)
> > > > >> You
> > > > >> > > should already have received notification emails for all of
> the
> > O
> > > > >> > > revisions, and so the following emails describe only the N
> > > revisions
> > > > >> from
> > > > >> > > the common base, B. Any revisions marked "omit" are not gone;
> > > other
> > > > >> > > references still refer to them. Any revisions marked "discard"
> > are
> > > > >> gone
> > > > >> > > forever. The 41 revisions listed above as "new" are entirely
> new
> > > to
> > > > >> this
> > > > >> > > repository and will be described in separate emails. The
> > revisions
> > > > >> listed
> > > > >> > > as "add" were already present in the repository and have only
> > been
> > > > >> added
> > > > >> > to
> > > > >> > > this reference.
> > > > >> > >
> > > > >> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三
> > > > >> 18:08写道：
> > > > >> > >
> > > > >> > > > Hi all,
> > > > >> > > >
> > > > >> > > > Something happened during the generation of the 1.30.0
> release
> > > > >> > candidate
> > > > >> > > > and the git history is somewhat broken.
> > > > >> > > >
> > > > >> > > > If you use the GitHub repo and you try to pull (DON'T DO IT
> > NOW)
> > > > >> > changes
> > > > >> > > > from master to update your local copy you will see that a
> > merge
> > > > >> commit
> > > > >> > is
> > > > >> > > > necessary which is not normal.
> > > > >> > > >
> > > > >> > > > Moreover, if you check the JIRAs resolved in this release
> > (e.g.,
> > > > >> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
> > > > >> indicates
> > > > >> > > the
> > > > >> > > > commit resolving the issue does not belong to any
> repository.
> > > > >> > > >
> > > > >> > > > From the above it seems there has been a force push to
> master.
> > > > >> Looking
> > > > >> > at
> > > > >> > > > the recent commits [3], I see something like a big rebase
> but
> > > not
> > > > >> sure
> > > > >> > > how
> > > > >> > > > we ended up with this situation and why it was necessary.
> > > > >> > > >
> > > > >> > > > Going forward, I think the first step is to understand what
> > > > >> happened
> > > > >> so
> > > > >> > > > that we avoid this reappearing in the future and the second
> > step
> > > > >> is
> > > > >> to
> > > > >> > > > restore the master branch (and others if affected) to its
> > > previous
> > > > >> > state
> > > > >> > > > from someone's valid local copy; probably this will
> > necessitate
> > > > >> another
> > > > >> > > > force-push.
> > > > >> > > >
> > > > >> > > > I am not doing anything for now till we agree on how we want
> > to
> > > > >> address
> > > > >> > > > this issue.
> > > > >> > > >
> > > > >> > > > Best,
> > > > >> > > > Stamatis
> > > > >> > > >
> > > > >> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > > > >> > > > [2]
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > > > >> > > > [3]
> > > > >> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > >
> > >
> >
>
Re: Broken history after force pushing to master
Posted by Ruben Q L <ru...@gmail.com>.
Hello,
Thanks everyone for helping with the issue, especially Stamatis for
carrying out the restore.
I agree with leaving the possibility of force push into master, since it
can be convenient in certain (very specific) cases.
Regarding this:
In step 2, I found the following commits in site branch but not in master
branch (through git log master..site):
...
Later, I found that these changes were also in the master branch (with
different commit hashes) ...
I can understand the confusion considering how the instruction is phrased
[1]:
«Make sure master branch and site branch are in sync, i.e. there is no
commit on site that has not been applied also to master.»
I think it was me who introduced this sentence, it should be clarified to
avoid the same problem in the future. Maybe by adding something along the
lines:
«Make sure master branch and site branch are in sync, i.e. there is no
commit on site that has not been applied also to master. We are talking
about the commit content, you need to pay attention to the commit message
and change, not hash: it is normal to have the same change in site and
master, but with different hashes.»
We could add this clarification later after the RC process, or we can take
advantage of the RC PR [2], which already touches the howto.md file (where
the problematic sentences is located). Liya Fan, as release manager, I
think it's up to you.
Best,
Ruben
[1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
[2] https://github.com/apache/calcite/pull/2741
On Thu, Mar 10, 2022 at 9:50 AM Fan Liya <li...@gmail.com> wrote:
> Hi Stamatis,
>
> Thanks a lot for your effort.
> I just tested, and the master branch is in consistent state with my local
> back-up. So I think it has restored to the original state.
>
> I have submitted a PR for the release note (
> https://github.com/apache/calcite/pull/2741).
> After it gets merged, I will prepare another build (RC2) and restart the
> voting process.
>
> Thanks again for your kind help.
>
> Best,
> Liya Fan
>
>
> Stamatis Zampetakis <za...@gmail.com> 于2022年3月10日周四 17:36写道：
>
> > Thanks for the clarifications Liya.
> >
> > I restored the master branch to its previous state and aligned master and
> > site.
> > Now we can proceed with the release. Normally there shouldn't be a need
> to
> > force-push again during this release.
> >
> > I don't think we want to disable force pushing altogether.
> > Without force pushing if we accidentally merge things to the repo we
> > wouldn't have a way to fix this easily.
> > A trivial example that comes to mind is putting a wrong JIRA id in the
> > commit message.
> > Leaving the commit message as is, will not be the end of the world but it
> > can be annoying when in the future people will get redirected to a wrong
> > jira.
> > Other examples include accidentally introducing merge commits etc.
> >
> > Best,
> > Stamatis
> >
> >
> > On Thu, Mar 10, 2022 at 6:28 AM stanilovsky evgeny <
> > estanilovskiy@gridgain.com> wrote:
> >
> > > Just notice - github allows to disable a force push into master branch.
> > >
> > > > It's not the first time that we have had small problems with history
> so
> > > > no
> > > > worries.
> > > > Thankfully with the help of commit@calcite list we can always find a
> > > way
> > > > to
> > > > fix things as long as we identify the problem soon enough.
> > > >
> > > > According to the change log [1] the last commit before force pushing
> > was
> > > > (dcbc493), which corresponds to CALCITE-5019.
> > > >
> > > > * -- * -- B -- O -- O -- O (dcbc493)
> > > > \
> > > > N -- N -- N refs/heads/master (c3dbf52)
> > > >
> > > > According to [2] the full commit id
> > > > is dcbc493bf699d961427952c5efc047b76d859096.
> > > >
> > > > In order to restore the master branch in the state that it was before
> > the
> > > > force-push (before release) I plan to do the following steps:
> > > >
> > > > git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> > > > git checkout dcbc493bf699d961427952c5efc047b76d859096
> > > > git branch -D master
> > > > git switch -c master
> > > > git push origin master -f
> > > >
> > > > I will apply the above sequence in 12h from now to give some time to
> > > > others
> > > > to react if necessary.
> > > >
> > > > Obviously this will nuke out any current release candidate so we will
> > > > need
> > > > to cancel existing votes and create an RC2.
> > > >
> > > > There has been a force push also to the site branch but doesn't
> matter
> > > > much
> > > > since we can force push master to site after the release is
> finalized.
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > > [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> > > >
> > > >
> > > > On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> > > >
> > > >> Hello Liya,
> > > >>
> > > >> No worries, we all make mistakes.
> > > >> I think the sequence of steps that you describe looks like a
> plausible
> > > >> explanation for how we get into this situation. Do you know (from
> step
> > > >> 2)
> > > >> which commits were in site branch that were not in master?
> > > >> If in the future you (or anybody else) get blocked or experience any
> > > >> problem on a certain step during the release process, do not
> hesitate
> > to
> > > >> send an email to the dev list with subject "[HELP] ..." describing
> the
> > > >> issue. In my experience, someone from the community will assist
> > > >> relatively
> > > >> fast.
> > > >>
> > > >> Any git expert with a clear idea on how to restore the master
> branch?
> > > >>
> > > >> Best,
> > > >> Ruben
> > > >>
> > > >>
> > > >> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com>
> wrote:
> > > >>
> > > >> > Hi all,
> > > >> >
> > > >> > I think the broken history was caused by this:
> > > >> >
> > > >> > 1. In document "Making a release candidate [1]", it says "Make
> sure
> > > >> master
> > > >> > branch and site branch are in sync".
> > > >> > 2. I checked the two branches, and find they have diverged. Some
> > > >> commits
> > > >> in
> > > >> > the site branch are not in the master branch.
> > > >> > 3. I tried the method given in the document "git reset --hard
> site",
> > > >> but
> > > >> it
> > > >> > didn't work.
> > > >> > 3. I tried to cherry-pick the commits to master, but it required
> > > >> resolving
> > > >> > conflicts, because the committing order was not correct.
> > > >> > 4. So I used "git rebase -i" to insert the commits into the
> "right"
> > > >> place
> > > >> > of the master branch.
> > > >> > 5. Finally, I pushed the result to the original master branch.
> > > >> >
> > > >> > I think that is the reason for the broken history. Really sorry
> for
> > > >> the
> > > >> > trouble.
> > > >> > If needed, I can restore the original master branch. I have backed
> > > up
> > > >> the
> > > >> > branch.
> > > >> >
> > > >> > Best,
> > > >> > Liya Fan
> > > >> >
> > > >> > [1]
> > > >>
> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> > > >> >
> > > >> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> > > >> >
> > > >> > > Hi. Stamatis. I agree we need to address this issue first.
> > > >> > > I find some relative descriptions at end of the email
> > > >> > >
> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4.
> > > So
> > > >> it
> > > >> > is
> > > >> > > a force push. Sorry I am not very good at Github job flow. But I
> > > >> think
> > > >> it
> > > >> > > describes what happened according to the appearances. So I hope
> > this
> > > >> can
> > > >> > > help.
> > > >> > >
> > > >> > > This update added new revisions after undoing existing
> revisions.
> > > >> That
> > > >> is
> > > >> > > to say, some revisions that were in the old version of the
> branch
> > > >> are
> > > >> not
> > > >> > > in the new version. This situation occurs when a user --force
> > > >> pushes a
> > > >> > > change and generates a repository containing something like
> this:
> > > *
> > > >> --
> > > >> *
> > > >> > --
> > > >> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master
> > (c3dbf52)
> > > >> You
> > > >> > > should already have received notification emails for all of the
> O
> > > >> > > revisions, and so the following emails describe only the N
> > revisions
> > > >> from
> > > >> > > the common base, B. Any revisions marked "omit" are not gone;
> > other
> > > >> > > references still refer to them. Any revisions marked "discard"
> are
> > > >> gone
> > > >> > > forever. The 41 revisions listed above as "new" are entirely new
> > to
> > > >> this
> > > >> > > repository and will be described in separate emails. The
> revisions
> > > >> listed
> > > >> > > as "add" were already present in the repository and have only
> been
> > > >> added
> > > >> > to
> > > >> > > this reference.
> > > >> > >
> > > >> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三
> > > >> 18:08写道：
> > > >> > >
> > > >> > > > Hi all,
> > > >> > > >
> > > >> > > > Something happened during the generation of the 1.30.0 release
> > > >> > candidate
> > > >> > > > and the git history is somewhat broken.
> > > >> > > >
> > > >> > > > If you use the GitHub repo and you try to pull (DON'T DO IT
> NOW)
> > > >> > changes
> > > >> > > > from master to update your local copy you will see that a
> merge
> > > >> commit
> > > >> > is
> > > >> > > > necessary which is not normal.
> > > >> > > >
> > > >> > > > Moreover, if you check the JIRAs resolved in this release
> (e.g.,
> > > >> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
> > > >> indicates
> > > >> > > the
> > > >> > > > commit resolving the issue does not belong to any repository.
> > > >> > > >
> > > >> > > > From the above it seems there has been a force push to master.
> > > >> Looking
> > > >> > at
> > > >> > > > the recent commits [3], I see something like a big rebase but
> > not
> > > >> sure
> > > >> > > how
> > > >> > > > we ended up with this situation and why it was necessary.
> > > >> > > >
> > > >> > > > Going forward, I think the first step is to understand what
> > > >> happened
> > > >> so
> > > >> > > > that we avoid this reappearing in the future and the second
> step
> > > >> is
> > > >> to
> > > >> > > > restore the master branch (and others if affected) to its
> > previous
> > > >> > state
> > > >> > > > from someone's valid local copy; probably this will
> necessitate
> > > >> another
> > > >> > > > force-push.
> > > >> > > >
> > > >> > > > I am not doing anything for now till we agree on how we want
> to
> > > >> address
> > > >> > > > this issue.
> > > >> > > >
> > > >> > > > Best,
> > > >> > > > Stamatis
> > > >> > > >
> > > >> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > > >> > > > [2]
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > > >> > > > [3]
> > > >> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > >> > > >
> > > >> > >
> > > >> >
> > >
> >
>
Re: Broken history after force pushing to master
Posted by Fan Liya <li...@gmail.com>.
Hi Stamatis,
Thanks a lot for your effort.
I just tested, and the master branch is in consistent state with my local
back-up. So I think it has restored to the original state.
I have submitted a PR for the release note (
https://github.com/apache/calcite/pull/2741).
After it gets merged, I will prepare another build (RC2) and restart the
voting process.
Thanks again for your kind help.
Best,
Liya Fan
Stamatis Zampetakis <za...@gmail.com> 于2022年3月10日周四 17:36写道：
> Thanks for the clarifications Liya.
>
> I restored the master branch to its previous state and aligned master and
> site.
> Now we can proceed with the release. Normally there shouldn't be a need to
> force-push again during this release.
>
> I don't think we want to disable force pushing altogether.
> Without force pushing if we accidentally merge things to the repo we
> wouldn't have a way to fix this easily.
> A trivial example that comes to mind is putting a wrong JIRA id in the
> commit message.
> Leaving the commit message as is, will not be the end of the world but it
> can be annoying when in the future people will get redirected to a wrong
> jira.
> Other examples include accidentally introducing merge commits etc.
>
> Best,
> Stamatis
>
>
> On Thu, Mar 10, 2022 at 6:28 AM stanilovsky evgeny <
> estanilovskiy@gridgain.com> wrote:
>
> > Just notice - github allows to disable a force push into master branch.
> >
> > > It's not the first time that we have had small problems with history so
> > > no
> > > worries.
> > > Thankfully with the help of commit@calcite list we can always find a
> > way
> > > to
> > > fix things as long as we identify the problem soon enough.
> > >
> > > According to the change log [1] the last commit before force pushing
> was
> > > (dcbc493), which corresponds to CALCITE-5019.
> > >
> > > * -- * -- B -- O -- O -- O (dcbc493)
> > > \
> > > N -- N -- N refs/heads/master (c3dbf52)
> > >
> > > According to [2] the full commit id
> > > is dcbc493bf699d961427952c5efc047b76d859096.
> > >
> > > In order to restore the master branch in the state that it was before
> the
> > > force-push (before release) I plan to do the following steps:
> > >
> > > git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> > > git checkout dcbc493bf699d961427952c5efc047b76d859096
> > > git branch -D master
> > > git switch -c master
> > > git push origin master -f
> > >
> > > I will apply the above sequence in 12h from now to give some time to
> > > others
> > > to react if necessary.
> > >
> > > Obviously this will nuke out any current release candidate so we will
> > > need
> > > to cancel existing votes and create an RC2.
> > >
> > > There has been a force push also to the site branch but doesn't matter
> > > much
> > > since we can force push master to site after the release is finalized.
> > >
> > > Best,
> > > Stamatis
> > >
> > > [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> > >
> > >
> > > On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> > >
> > >> Hello Liya,
> > >>
> > >> No worries, we all make mistakes.
> > >> I think the sequence of steps that you describe looks like a plausible
> > >> explanation for how we get into this situation. Do you know (from step
> > >> 2)
> > >> which commits were in site branch that were not in master?
> > >> If in the future you (or anybody else) get blocked or experience any
> > >> problem on a certain step during the release process, do not hesitate
> to
> > >> send an email to the dev list with subject "[HELP] ..." describing the
> > >> issue. In my experience, someone from the community will assist
> > >> relatively
> > >> fast.
> > >>
> > >> Any git expert with a clear idea on how to restore the master branch?
> > >>
> > >> Best,
> > >> Ruben
> > >>
> > >>
> > >> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > I think the broken history was caused by this:
> > >> >
> > >> > 1. In document "Making a release candidate [1]", it says "Make sure
> > >> master
> > >> > branch and site branch are in sync".
> > >> > 2. I checked the two branches, and find they have diverged. Some
> > >> commits
> > >> in
> > >> > the site branch are not in the master branch.
> > >> > 3. I tried the method given in the document "git reset --hard site",
> > >> but
> > >> it
> > >> > didn't work.
> > >> > 3. I tried to cherry-pick the commits to master, but it required
> > >> resolving
> > >> > conflicts, because the committing order was not correct.
> > >> > 4. So I used "git rebase -i" to insert the commits into the "right"
> > >> place
> > >> > of the master branch.
> > >> > 5. Finally, I pushed the result to the original master branch.
> > >> >
> > >> > I think that is the reason for the broken history. Really sorry for
> > >> the
> > >> > trouble.
> > >> > If needed, I can restore the original master branch. I have backed
> > up
> > >> the
> > >> > branch.
> > >> >
> > >> > Best,
> > >> > Liya Fan
> > >> >
> > >> > [1]
> > >> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> > >> >
> > >> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> > >> >
> > >> > > Hi. Stamatis. I agree we need to address this issue first.
> > >> > > I find some relative descriptions at end of the email
> > >> > > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4.
> > So
> > >> it
> > >> > is
> > >> > > a force push. Sorry I am not very good at Github job flow. But I
> > >> think
> > >> it
> > >> > > describes what happened according to the appearances. So I hope
> this
> > >> can
> > >> > > help.
> > >> > >
> > >> > > This update added new revisions after undoing existing revisions.
> > >> That
> > >> is
> > >> > > to say, some revisions that were in the old version of the branch
> > >> are
> > >> not
> > >> > > in the new version. This situation occurs when a user --force
> > >> pushes a
> > >> > > change and generates a repository containing something like this:
> > *
> > >> --
> > >> *
> > >> > --
> > >> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master
> (c3dbf52)
> > >> You
> > >> > > should already have received notification emails for all of the O
> > >> > > revisions, and so the following emails describe only the N
> revisions
> > >> from
> > >> > > the common base, B. Any revisions marked "omit" are not gone;
> other
> > >> > > references still refer to them. Any revisions marked "discard" are
> > >> gone
> > >> > > forever. The 41 revisions listed above as "new" are entirely new
> to
> > >> this
> > >> > > repository and will be described in separate emails. The revisions
> > >> listed
> > >> > > as "add" were already present in the repository and have only been
> > >> added
> > >> > to
> > >> > > this reference.
> > >> > >
> > >> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三
> > >> 18:08写道：
> > >> > >
> > >> > > > Hi all,
> > >> > > >
> > >> > > > Something happened during the generation of the 1.30.0 release
> > >> > candidate
> > >> > > > and the git history is somewhat broken.
> > >> > > >
> > >> > > > If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> > >> > changes
> > >> > > > from master to update your local copy you will see that a merge
> > >> commit
> > >> > is
> > >> > > > necessary which is not normal.
> > >> > > >
> > >> > > > Moreover, if you check the JIRAs resolved in this release (e.g.,
> > >> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
> > >> indicates
> > >> > > the
> > >> > > > commit resolving the issue does not belong to any repository.
> > >> > > >
> > >> > > > From the above it seems there has been a force push to master.
> > >> Looking
> > >> > at
> > >> > > > the recent commits [3], I see something like a big rebase but
> not
> > >> sure
> > >> > > how
> > >> > > > we ended up with this situation and why it was necessary.
> > >> > > >
> > >> > > > Going forward, I think the first step is to understand what
> > >> happened
> > >> so
> > >> > > > that we avoid this reappearing in the future and the second step
> > >> is
> > >> to
> > >> > > > restore the master branch (and others if affected) to its
> previous
> > >> > state
> > >> > > > from someone's valid local copy; probably this will necessitate
> > >> another
> > >> > > > force-push.
> > >> > > >
> > >> > > > I am not doing anything for now till we agree on how we want to
> > >> address
> > >> > > > this issue.
> > >> > > >
> > >> > > > Best,
> > >> > > > Stamatis
> > >> > > >
> > >> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > >> > > > [2]
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > >> > > > [3]
> > >> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > >> > > >
> > >> > >
> > >> >
> >
>
Re: Broken history after force pushing to master
Posted by Stamatis Zampetakis <za...@gmail.com>.
Thanks for the clarifications Liya.
I restored the master branch to its previous state and aligned master and
site.
Now we can proceed with the release. Normally there shouldn't be a need to
force-push again during this release.
I don't think we want to disable force pushing altogether.
Without force pushing if we accidentally merge things to the repo we
wouldn't have a way to fix this easily.
A trivial example that comes to mind is putting a wrong JIRA id in the
commit message.
Leaving the commit message as is, will not be the end of the world but it
can be annoying when in the future people will get redirected to a wrong
jira.
Other examples include accidentally introducing merge commits etc.
Best,
Stamatis
On Thu, Mar 10, 2022 at 6:28 AM stanilovsky evgeny <
estanilovskiy@gridgain.com> wrote:
> Just notice - github allows to disable a force push into master branch.
>
> > It's not the first time that we have had small problems with history so
> > no
> > worries.
> > Thankfully with the help of commit@calcite list we can always find a
> way
> > to
> > fix things as long as we identify the problem soon enough.
> >
> > According to the change log [1] the last commit before force pushing was
> > (dcbc493), which corresponds to CALCITE-5019.
> >
> > * -- * -- B -- O -- O -- O (dcbc493)
> > \
> > N -- N -- N refs/heads/master (c3dbf52)
> >
> > According to [2] the full commit id
> > is dcbc493bf699d961427952c5efc047b76d859096.
> >
> > In order to restore the master branch in the state that it was before the
> > force-push (before release) I plan to do the following steps:
> >
> > git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> > git checkout dcbc493bf699d961427952c5efc047b76d859096
> > git branch -D master
> > git switch -c master
> > git push origin master -f
> >
> > I will apply the above sequence in 12h from now to give some time to
> > others
> > to react if necessary.
> >
> > Obviously this will nuke out any current release candidate so we will
> > need
> > to cancel existing votes and create an RC2.
> >
> > There has been a force push also to the site branch but doesn't matter
> > much
> > since we can force push master to site after the release is finalized.
> >
> > Best,
> > Stamatis
> >
> > [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
> >
> >
> > On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> >
> >> Hello Liya,
> >>
> >> No worries, we all make mistakes.
> >> I think the sequence of steps that you describe looks like a plausible
> >> explanation for how we get into this situation. Do you know (from step
> >> 2)
> >> which commits were in site branch that were not in master?
> >> If in the future you (or anybody else) get blocked or experience any
> >> problem on a certain step during the release process, do not hesitate to
> >> send an email to the dev list with subject "[HELP] ..." describing the
> >> issue. In my experience, someone from the community will assist
> >> relatively
> >> fast.
> >>
> >> Any git expert with a clear idea on how to restore the master branch?
> >>
> >> Best,
> >> Ruben
> >>
> >>
> >> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
> >>
> >> > Hi all,
> >> >
> >> > I think the broken history was caused by this:
> >> >
> >> > 1. In document "Making a release candidate [1]", it says "Make sure
> >> master
> >> > branch and site branch are in sync".
> >> > 2. I checked the two branches, and find they have diverged. Some
> >> commits
> >> in
> >> > the site branch are not in the master branch.
> >> > 3. I tried the method given in the document "git reset --hard site",
> >> but
> >> it
> >> > didn't work.
> >> > 3. I tried to cherry-pick the commits to master, but it required
> >> resolving
> >> > conflicts, because the committing order was not correct.
> >> > 4. So I used "git rebase -i" to insert the commits into the "right"
> >> place
> >> > of the master branch.
> >> > 5. Finally, I pushed the result to the original master branch.
> >> >
> >> > I think that is the reason for the broken history. Really sorry for
> >> the
> >> > trouble.
> >> > If needed, I can restore the original master branch. I have backed
> up
> >> the
> >> > branch.
> >> >
> >> > Best,
> >> > Liya Fan
> >> >
> >> > [1]
> >> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >> >
> >> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> >> >
> >> > > Hi. Stamatis. I agree we need to address this issue first.
> >> > > I find some relative descriptions at end of the email
> >> > > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4.
> So
> >> it
> >> > is
> >> > > a force push. Sorry I am not very good at Github job flow. But I
> >> think
> >> it
> >> > > describes what happened according to the appearances. So I hope this
> >> can
> >> > > help.
> >> > >
> >> > > This update added new revisions after undoing existing revisions.
> >> That
> >> is
> >> > > to say, some revisions that were in the old version of the branch
> >> are
> >> not
> >> > > in the new version. This situation occurs when a user --force
> >> pushes a
> >> > > change and generates a repository containing something like this:
> *
> >> --
> >> *
> >> > --
> >> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
> >> You
> >> > > should already have received notification emails for all of the O
> >> > > revisions, and so the following emails describe only the N revisions
> >> from
> >> > > the common base, B. Any revisions marked "omit" are not gone; other
> >> > > references still refer to them. Any revisions marked "discard" are
> >> gone
> >> > > forever. The 41 revisions listed above as "new" are entirely new to
> >> this
> >> > > repository and will be described in separate emails. The revisions
> >> listed
> >> > > as "add" were already present in the repository and have only been
> >> added
> >> > to
> >> > > this reference.
> >> > >
> >> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三
> >> 18:08写道：
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > Something happened during the generation of the 1.30.0 release
> >> > candidate
> >> > > > and the git history is somewhat broken.
> >> > > >
> >> > > > If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> >> > changes
> >> > > > from master to update your local copy you will see that a merge
> >> commit
> >> > is
> >> > > > necessary which is not normal.
> >> > > >
> >> > > > Moreover, if you check the JIRAs resolved in this release (e.g.,
> >> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
> >> indicates
> >> > > the
> >> > > > commit resolving the issue does not belong to any repository.
> >> > > >
> >> > > > From the above it seems there has been a force push to master.
> >> Looking
> >> > at
> >> > > > the recent commits [3], I see something like a big rebase but not
> >> sure
> >> > > how
> >> > > > we ended up with this situation and why it was necessary.
> >> > > >
> >> > > > Going forward, I think the first step is to understand what
> >> happened
> >> so
> >> > > > that we avoid this reappearing in the future and the second step
> >> is
> >> to
> >> > > > restore the master branch (and others if affected) to its previous
> >> > state
> >> > > > from someone's valid local copy; probably this will necessitate
> >> another
> >> > > > force-push.
> >> > > >
> >> > > > I am not doing anything for now till we agree on how we want to
> >> address
> >> > > > this issue.
> >> > > >
> >> > > > Best,
> >> > > > Stamatis
> >> > > >
> >> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> >> > > > [2]
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> >> > > > [3]
> >> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> >> > > >
> >> > >
> >> >
>
Re: Broken history after force pushing to master
Posted by stanilovsky evgeny <es...@gridgain.com>.
Just notice - github allows to disable a force push into master branch.
> It's not the first time that we have had small problems with history so
> no
> worries.
> Thankfully with the help of commit@calcite list we can always find a way
> to
> fix things as long as we identify the problem soon enough.
>
> According to the change log [1] the last commit before force pushing was
> (dcbc493), which corresponds to CALCITE-5019.
>
> * -- * -- B -- O -- O -- O (dcbc493)
> \
> N -- N -- N refs/heads/master (c3dbf52)
>
> According to [2] the full commit id
> is dcbc493bf699d961427952c5efc047b76d859096.
>
> In order to restore the master branch in the state that it was before the
> force-push (before release) I plan to do the following steps:
>
> git fetch origin dcbc493bf699d961427952c5efc047b76d859096
> git checkout dcbc493bf699d961427952c5efc047b76d859096
> git branch -D master
> git switch -c master
> git push origin master -f
>
> I will apply the above sequence in 12h from now to give some time to
> others
> to react if necessary.
>
> Obviously this will nuke out any current release candidate so we will
> need
> to cancel existing votes and create an RC2.
>
> There has been a force push also to the site branch but doesn't matter
> much
> since we can force push master to site after the release is finalized.
>
> Best,
> Stamatis
>
> [1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> [2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
>
>
> On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
>
>> Hello Liya,
>>
>> No worries, we all make mistakes.
>> I think the sequence of steps that you describe looks like a plausible
>> explanation for how we get into this situation. Do you know (from step
>> 2)
>> which commits were in site branch that were not in master?
>> If in the future you (or anybody else) get blocked or experience any
>> problem on a certain step during the release process, do not hesitate to
>> send an email to the dev list with subject "[HELP] ..." describing the
>> issue. In my experience, someone from the community will assist
>> relatively
>> fast.
>>
>> Any git expert with a clear idea on how to restore the master branch?
>>
>> Best,
>> Ruben
>>
>>
>> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > I think the broken history was caused by this:
>> >
>> > 1. In document "Making a release candidate [1]", it says "Make sure
>> master
>> > branch and site branch are in sync".
>> > 2. I checked the two branches, and find they have diverged. Some
>> commits
>> in
>> > the site branch are not in the master branch.
>> > 3. I tried the method given in the document "git reset --hard site",
>> but
>> it
>> > didn't work.
>> > 3. I tried to cherry-pick the commits to master, but it required
>> resolving
>> > conflicts, because the committing order was not correct.
>> > 4. So I used "git rebase -i" to insert the commits into the "right"
>> place
>> > of the master branch.
>> > 5. Finally, I pushed the result to the original master branch.
>> >
>> > I think that is the reason for the broken history. Really sorry for
>> the
>> > trouble.
>> > If needed, I can restore the original master branch. I have backed up
>> the
>> > branch.
>> >
>> > Best,
>> > Liya Fan
>> >
>> > [1]
>> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>> >
>> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
>> >
>> > > Hi. Stamatis. I agree we need to address this issue first.
>> > > I find some relative descriptions at end of the email
>> > > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So
>> it
>> > is
>> > > a force push. Sorry I am not very good at Github job flow. But I
>> think
>> it
>> > > describes what happened according to the appearances. So I hope this
>> can
>> > > help.
>> > >
>> > > This update added new revisions after undoing existing revisions.
>> That
>> is
>> > > to say, some revisions that were in the old version of the branch
>> are
>> not
>> > > in the new version. This situation occurs when a user --force
>> pushes a
>> > > change and generates a repository containing something like this: *
>> --
>> *
>> > --
>> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
>> You
>> > > should already have received notification emails for all of the O
>> > > revisions, and so the following emails describe only the N revisions
>> from
>> > > the common base, B. Any revisions marked "omit" are not gone; other
>> > > references still refer to them. Any revisions marked "discard" are
>> gone
>> > > forever. The 41 revisions listed above as "new" are entirely new to
>> this
>> > > repository and will be described in separate emails. The revisions
>> listed
>> > > as "add" were already present in the repository and have only been
>> added
>> > to
>> > > this reference.
>> > >
>> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三
>> 18:08写道：
>> > >
>> > > > Hi all,
>> > > >
>> > > > Something happened during the generation of the 1.30.0 release
>> > candidate
>> > > > and the git history is somewhat broken.
>> > > >
>> > > > If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
>> > changes
>> > > > from master to update your local copy you will see that a merge
>> commit
>> > is
>> > > > necessary which is not normal.
>> > > >
>> > > > Moreover, if you check the JIRAs resolved in this release (e.g.,
>> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
>> indicates
>> > > the
>> > > > commit resolving the issue does not belong to any repository.
>> > > >
>> > > > From the above it seems there has been a force push to master.
>> Looking
>> > at
>> > > > the recent commits [3], I see something like a big rebase but not
>> sure
>> > > how
>> > > > we ended up with this situation and why it was necessary.
>> > > >
>> > > > Going forward, I think the first step is to understand what
>> happened
>> so
>> > > > that we avoid this reappearing in the future and the second step
>> is
>> to
>> > > > restore the master branch (and others if affected) to its previous
>> > state
>> > > > from someone's valid local copy; probably this will necessitate
>> another
>> > > > force-push.
>> > > >
>> > > > I am not doing anything for now till we agree on how we want to
>> address
>> > > > this issue.
>> > > >
>> > > > Best,
>> > > > Stamatis
>> > > >
>> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
>> > > > [2]
>> > > >
>> > > >
>> > >
>> >
>> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
>> > > > [3]
>> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
>> > > >
>> > >
>> >
Re: Broken history after force pushing to master
Posted by Stamatis Zampetakis <za...@gmail.com>.
It's not the first time that we have had small problems with history so no
worries.
Thankfully with the help of commit@calcite list we can always find a way to
fix things as long as we identify the problem soon enough.
According to the change log [1] the last commit before force pushing was
(dcbc493), which corresponds to CALCITE-5019.
* -- * -- B -- O -- O -- O (dcbc493)
\
N -- N -- N refs/heads/master (c3dbf52)
According to [2] the full commit id
is dcbc493bf699d961427952c5efc047b76d859096.
In order to restore the master branch in the state that it was before the
force-push (before release) I plan to do the following steps:
git fetch origin dcbc493bf699d961427952c5efc047b76d859096
git checkout dcbc493bf699d961427952c5efc047b76d859096
git branch -D master
git switch -c master
git push origin master -f
I will apply the above sequence in 12h from now to give some time to others
to react if necessary.
Obviously this will nuke out any current release candidate so we will need
to cancel existing votes and create an RC2.
There has been a force push also to the site branch but doesn't matter much
since we can force push master to site after the release is finalized.
Best,
Stamatis
[1] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
[2] https://lists.apache.org/thread/rvngk5tygfoyoc0klhwpo717mrngkdrw
On Wed, Mar 9, 2022 at 6:44 PM Ruben Q L <ru...@gmail.com> wrote:
> Hello Liya,
>
> No worries, we all make mistakes.
> I think the sequence of steps that you describe looks like a plausible
> explanation for how we get into this situation. Do you know (from step 2)
> which commits were in site branch that were not in master?
> If in the future you (or anybody else) get blocked or experience any
> problem on a certain step during the release process, do not hesitate to
> send an email to the dev list with subject "[HELP] ..." describing the
> issue. In my experience, someone from the community will assist relatively
> fast.
>
> Any git expert with a clear idea on how to restore the master branch?
>
> Best,
> Ruben
>
>
> On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
>
> > Hi all,
> >
> > I think the broken history was caused by this:
> >
> > 1. In document "Making a release candidate [1]", it says "Make sure
> master
> > branch and site branch are in sync".
> > 2. I checked the two branches, and find they have diverged. Some commits
> in
> > the site branch are not in the master branch.
> > 3. I tried the method given in the document "git reset --hard site", but
> it
> > didn't work.
> > 3. I tried to cherry-pick the commits to master, but it required
> resolving
> > conflicts, because the committing order was not correct.
> > 4. So I used "git rebase -i" to insert the commits into the "right" place
> > of the master branch.
> > 5. Finally, I pushed the result to the original master branch.
> >
> > I think that is the reason for the broken history. Really sorry for the
> > trouble.
> > If needed, I can restore the original master branch. I have backed up the
> > branch.
> >
> > Best,
> > Liya Fan
> >
> > [1]
> https://calcite.apache.org/docs/howto.html#making-a-release-candidate
> >
> > xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> >
> > > Hi. Stamatis. I agree we need to address this issue first.
> > > I find some relative descriptions at end of the email
> > > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So
> it
> > is
> > > a force push. Sorry I am not very good at Github job flow. But I think
> it
> > > describes what happened according to the appearances. So I hope this
> can
> > > help.
> > >
> > > This update added new revisions after undoing existing revisions. That
> is
> > > to say, some revisions that were in the old version of the branch are
> not
> > > in the new version. This situation occurs when a user --force pushes a
> > > change and generates a repository containing something like this: * --
> *
> > --
> > > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52)
> You
> > > should already have received notification emails for all of the O
> > > revisions, and so the following emails describe only the N revisions
> from
> > > the common base, B. Any revisions marked "omit" are not gone; other
> > > references still refer to them. Any revisions marked "discard" are gone
> > > forever. The 41 revisions listed above as "new" are entirely new to
> this
> > > repository and will be described in separate emails. The revisions
> listed
> > > as "add" were already present in the repository and have only been
> added
> > to
> > > this reference.
> > >
> > > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
> > >
> > > > Hi all,
> > > >
> > > > Something happened during the generation of the 1.30.0 release
> > candidate
> > > > and the git history is somewhat broken.
> > > >
> > > > If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> > changes
> > > > from master to update your local copy you will see that a merge
> commit
> > is
> > > > necessary which is not normal.
> > > >
> > > > Moreover, if you check the JIRAs resolved in this release (e.g.,
> > > > CALCITE-4991 [1]) you will notice that the comment [2] which
> indicates
> > > the
> > > > commit resolving the issue does not belong to any repository.
> > > >
> > > > From the above it seems there has been a force push to master.
> Looking
> > at
> > > > the recent commits [3], I see something like a big rebase but not
> sure
> > > how
> > > > we ended up with this situation and why it was necessary.
> > > >
> > > > Going forward, I think the first step is to understand what happened
> so
> > > > that we avoid this reappearing in the future and the second step is
> to
> > > > restore the master branch (and others if affected) to its previous
> > state
> > > > from someone's valid local copy; probably this will necessitate
> another
> > > > force-push.
> > > >
> > > > I am not doing anything for now till we agree on how we want to
> address
> > > > this issue.
> > > >
> > > > Best,
> > > > Stamatis
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > > > [2]
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > > > [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > > >
> > >
> >
>
Re: Broken history after force pushing to master
Posted by Ruben Q L <ru...@gmail.com>.
Hello Liya,
No worries, we all make mistakes.
I think the sequence of steps that you describe looks like a plausible
explanation for how we get into this situation. Do you know (from step 2)
which commits were in site branch that were not in master?
If in the future you (or anybody else) get blocked or experience any
problem on a certain step during the release process, do not hesitate to
send an email to the dev list with subject "[HELP] ..." describing the
issue. In my experience, someone from the community will assist relatively
fast.
Any git expert with a clear idea on how to restore the master branch?
Best,
Ruben
On Wed, Mar 9, 2022 at 1:32 PM Fan Liya <li...@gmail.com> wrote:
> Hi all,
>
> I think the broken history was caused by this:
>
> 1. In document "Making a release candidate [1]", it says "Make sure master
> branch and site branch are in sync".
> 2. I checked the two branches, and find they have diverged. Some commits in
> the site branch are not in the master branch.
> 3. I tried the method given in the document "git reset --hard site", but it
> didn't work.
> 3. I tried to cherry-pick the commits to master, but it required resolving
> conflicts, because the committing order was not correct.
> 4. So I used "git rebase -i" to insert the commits into the "right" place
> of the master branch.
> 5. Finally, I pushed the result to the original master branch.
>
> I think that is the reason for the broken history. Really sorry for the
> trouble.
> If needed, I can restore the original master branch. I have backed up the
> branch.
>
> Best,
> Liya Fan
>
> [1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
>
> xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
>
> > Hi. Stamatis. I agree we need to address this issue first.
> > I find some relative descriptions at end of the email
> > https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So it
> is
> > a force push. Sorry I am not very good at Github job flow. But I think it
> > describes what happened according to the appearances. So I hope this can
> > help.
> >
> > This update added new revisions after undoing existing revisions. That is
> > to say, some revisions that were in the old version of the branch are not
> > in the new version. This situation occurs when a user --force pushes a
> > change and generates a repository containing something like this: * -- *
> --
> > B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52) You
> > should already have received notification emails for all of the O
> > revisions, and so the following emails describe only the N revisions from
> > the common base, B. Any revisions marked "omit" are not gone; other
> > references still refer to them. Any revisions marked "discard" are gone
> > forever. The 41 revisions listed above as "new" are entirely new to this
> > repository and will be described in separate emails. The revisions listed
> > as "add" were already present in the repository and have only been added
> to
> > this reference.
> >
> > Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
> >
> > > Hi all,
> > >
> > > Something happened during the generation of the 1.30.0 release
> candidate
> > > and the git history is somewhat broken.
> > >
> > > If you use the GitHub repo and you try to pull (DON'T DO IT NOW)
> changes
> > > from master to update your local copy you will see that a merge commit
> is
> > > necessary which is not normal.
> > >
> > > Moreover, if you check the JIRAs resolved in this release (e.g.,
> > > CALCITE-4991 [1]) you will notice that the comment [2] which indicates
> > the
> > > commit resolving the issue does not belong to any repository.
> > >
> > > From the above it seems there has been a force push to master. Looking
> at
> > > the recent commits [3], I see something like a big rebase but not sure
> > how
> > > we ended up with this situation and why it was necessary.
> > >
> > > Going forward, I think the first step is to understand what happened so
> > > that we avoid this reappearing in the future and the second step is to
> > > restore the master branch (and others if affected) to its previous
> state
> > > from someone's valid local copy; probably this will necessitate another
> > > force-push.
> > >
> > > I am not doing anything for now till we agree on how we want to address
> > > this issue.
> > >
> > > Best,
> > > Stamatis
> > >
> > > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > > [2]
> > >
> > >
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > > [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> > >
> >
>
Re: Broken history after force pushing to master
Posted by Fan Liya <li...@gmail.com>.
Hi all,
I think the broken history was caused by this:
1. In document "Making a release candidate [1]", it says "Make sure master
branch and site branch are in sync".
2. I checked the two branches, and find they have diverged. Some commits in
the site branch are not in the master branch.
3. I tried the method given in the document "git reset --hard site", but it
didn't work.
3. I tried to cherry-pick the commits to master, but it required resolving
conflicts, because the committing order was not correct.
4. So I used "git rebase -i" to insert the commits into the "right" place
of the master branch.
5. Finally, I pushed the result to the original master branch.
I think that is the reason for the broken history. Really sorry for the
trouble.
If needed, I can restore the original master branch. I have backed up the
branch.
Best,
Liya Fan
[1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate
xiong duan <no...@gmail.com> 于2022年3月9日周三 19:35写道：
> Hi. Stamatis. I agree we need to address this issue first.
> I find some relative descriptions at end of the email
> https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So it is
> a force push. Sorry I am not very good at Github job flow. But I think it
> describes what happened according to the appearances. So I hope this can
> help.
>
> This update added new revisions after undoing existing revisions. That is
> to say, some revisions that were in the old version of the branch are not
> in the new version. This situation occurs when a user --force pushes a
> change and generates a repository containing something like this: * -- * --
> B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52) You
> should already have received notification emails for all of the O
> revisions, and so the following emails describe only the N revisions from
> the common base, B. Any revisions marked "omit" are not gone; other
> references still refer to them. Any revisions marked "discard" are gone
> forever. The 41 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails. The revisions listed
> as "add" were already present in the repository and have only been added to
> this reference.
>
> Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
>
> > Hi all,
> >
> > Something happened during the generation of the 1.30.0 release candidate
> > and the git history is somewhat broken.
> >
> > If you use the GitHub repo and you try to pull (DON'T DO IT NOW) changes
> > from master to update your local copy you will see that a merge commit is
> > necessary which is not normal.
> >
> > Moreover, if you check the JIRAs resolved in this release (e.g.,
> > CALCITE-4991 [1]) you will notice that the comment [2] which indicates
> the
> > commit resolving the issue does not belong to any repository.
> >
> > From the above it seems there has been a force push to master. Looking at
> > the recent commits [3], I see something like a big rebase but not sure
> how
> > we ended up with this situation and why it was necessary.
> >
> > Going forward, I think the first step is to understand what happened so
> > that we avoid this reappearing in the future and the second step is to
> > restore the master branch (and others if affected) to its previous state
> > from someone's valid local copy; probably this will necessitate another
> > force-push.
> >
> > I am not doing anything for now till we agree on how we want to address
> > this issue.
> >
> > Best,
> > Stamatis
> >
> > [1] https://issues.apache.org/jira/browse/CALCITE-4991
> > [2]
> >
> >
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> > [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
> >
>
Re: Broken history after force pushing to master
Posted by xiong duan <no...@gmail.com>.
Hi. Stamatis. I agree we need to address this issue first.
I find some relative descriptions at end of the email
https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4. So it is
a force push. Sorry I am not very good at Github job flow. But I think it
describes what happened according to the appearances. So I hope this can
help.
This update added new revisions after undoing existing revisions. That is
to say, some revisions that were in the old version of the branch are not
in the new version. This situation occurs when a user --force pushes a
change and generates a repository containing something like this: * -- * --
B -- O -- O -- O (dcbc493) \ N -- N -- N refs/heads/master (c3dbf52) You
should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions from
the common base, B. Any revisions marked "omit" are not gone; other
references still refer to them. Any revisions marked "discard" are gone
forever. The 41 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions listed
as "add" were already present in the repository and have only been added to
this reference.
Stamatis Zampetakis <za...@gmail.com> 于2022年3月9日周三 18:08写道：
> Hi all,
>
> Something happened during the generation of the 1.30.0 release candidate
> and the git history is somewhat broken.
>
> If you use the GitHub repo and you try to pull (DON'T DO IT NOW) changes
> from master to update your local copy you will see that a merge commit is
> necessary which is not normal.
>
> Moreover, if you check the JIRAs resolved in this release (e.g.,
> CALCITE-4991 [1]) you will notice that the comment [2] which indicates the
> commit resolving the issue does not belong to any repository.
>
> From the above it seems there has been a force push to master. Looking at
> the recent commits [3], I see something like a big rebase but not sure how
> we ended up with this situation and why it was necessary.
>
> Going forward, I think the first step is to understand what happened so
> that we avoid this reappearing in the future and the second step is to
> restore the master branch (and others if affected) to its previous state
> from someone's valid local copy; probably this will necessitate another
> force-push.
>
> I am not doing anything for now till we agree on how we want to address
> this issue.
>
> Best,
> Stamatis
>
> [1] https://issues.apache.org/jira/browse/CALCITE-4991
> [2]
>
> https://issues.apache.org/jira/browse/CALCITE-4991?focusedCommentId=17480091&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17480091
> [3] https://lists.apache.org/thread/gkvn5hlmm3jlcklgw9k9nodyhxvqmsw4
>