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