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 <jhyde.apa...@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 <liya.fa...@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 <rube...@gmail.com> > > Date: Sat Jan 29 19:04:14 2022 +0000 > > > > Site: update PMC Chair > > > > commit fabef057c536d56e10530b399543077abad03a24 > > Author: Jing Zhang <beyond1...@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 <eugen.s...@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 <alessandro.solima...@gmail.com> > > Date: Mon Jan 10 11:48:29 2022 +0100 > > > > Site: Add Alessandro Solimando as committer > > > > commit 664c4d3f9b0ec03071df6fef44b32169a275ea49 > > Author: mans2singh <mans2si...@yahoo.com> > > Date: Wed Jan 5 19:41:56 2022 -0500 > > > > Site: Fix typo in howto.md > > > > commit dd34953aa0b5af13e7e7fccd75b2f2e8fe9c8edd > > Author: nobigo <nobigo...@gmail.com> > > Date: Fri Dec 31 21:28:20 2021 +0800 > > > > Site: Change the javadoc title to Apache Calcite API > > > > commit d29aa09321ab14bd824e5465ddcfae8d16604134 > > Author: Guiyanakuang <guiyanaku...@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 <guiyanaku...@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 <guiyanaku...@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 <jhyde.apa...@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 <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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >
