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 <zabe...@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 <rube...@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 <liya.fa...@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 <nobigo...@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 <zabe...@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 >>>>> >>>> >>> >>
