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 >>>>>>> >>>>>> >>>>> >>>> >> >>
