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 <[email protected]> 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 <[email protected]> 于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 < > > [email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 于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 <[email protected]> 于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 > > > >> > > > > > > >> > > > > > >> > > > > > > >
