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 < estanilovs...@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 <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 > >> > > > > >> > > > >> > >
