My mistake. I was unaware of the --allow-unrelated-histories flag :) -- Michael Mior mm...@apache.org
Le mer. 10 nov. 2021 à 07:34, Dmitry Sysolyatin <dm.sysolya...@gmail.com> a écrit : > > No. hashes shouldn't change. > You can try the following steps and check: > > git pull https://github.com/apache/calcite.git > cd calcite > git remote add avatica https://github.com/apache/calcite-avatica > git fetch avatica > git merge avatica/master --allow-unrelated-histories > git add . && git commit -m "test" > > If you check the history log you can see that hash for the commit > https://github.com/apache/calcite-avatica/commit/4cf769f8ee32bb3520604e4f3284e6f233f90276 > remains the same > > On Wed, Nov 10, 2021 at 2:20 PM Michael Mior <mm...@apache.org> wrote: > > > > Actually, it is possible to preserve the history of commits when you > > merge > > > two repos - > > > > You can keep the history, but the hashes will necessarily change > > because they are based on a different parent. So it will be possible > > to see the changes, but the hashes would reference the old Avatica > > repository which would no longer be active. > > > > -- > > Michael Mior > > mm...@apache.org > > > > Le mer. 10 nov. 2021 à 06:47, Dmitry Sysolyatin > > <dm.sysolya...@gmail.com> a écrit : > > > > > > Actually, it is possible to preserve the history of commits when you > > merge > > > two repos - > > > > > https://stackoverflow.com/questions/17371150/moving-git-repository-content-to-another-repository-preserving-history > > > > > > On Tue, Nov 9, 2021 at 11:24 PM Julian Hyde <jhyde.apa...@gmail.com> > > wrote: > > > > > > > Merging the repositories is unnecessary, and a massive waste of time. > > > > > > > > Any supposed “time savings” due to the the merged repositories will be > > > > eaten up by dozens of small issues that will crop up long after the > > merge. > > > > > > > > I was release manager for Calcite and Avatica this time around and it > > took > > > > me about a week, because the process had changed since last time I was > > > > release manager. And now we’re going to change the process again? > > > > Absolutely fucking insane. > > > > > > > > Also, we will lose the history of the Avatica source code. All of the > > > > commit hashes for bugs fixed long ago will change. > > > > > > > > At the time that we split the repositories, I was probably against the > > > > idea, because it was work. Now that we’ve split, I am strongly against > > > > recombining the repositories. > > > > > > > > Honestly, people, we have better things to do. > > > > > > > > Julian > > > > > > > > > > > > > On Nov 9, 2021, at 1:03 PM, Stamatis Zampetakis <zabe...@gmail.com> > > > > wrote: > > > > > > > > > > The two projects have more or less the same release cadence, they're > > > > > maintained by the same community, they're written in the same > > language, > > > > and > > > > > they use the same build system. > > > > > > > > > > Although I understand the reasons the project was split in the first > > > > place, > > > > > at the moment I tend to agree that having them in the same repo > > would be > > > > > more practical. > > > > > > > > > > Truth is the merge may require quite a bit of work so we should take > > this > > > > > into consideration. > > > > > > > > > > If people prefer keeping the projects as they are I am perfectly fine > > > > with > > > > > that as well. I am leaving the decision to those who feel strongly > > about > > > > > this change. > > > > > > > > > > Best, > > > > > Stamatis > > > > > > > > > > > > > > > > > > > > On Tue, Nov 9, 2021, 7:46 PM Vladimir Ozerov <ppoze...@gmail.com> > > wrote: > > > > > > > > > >> +1 for a single repo. > > > > >> > > > > >> Вт, 9 нояб. 2021 г. в 19:22, Vladimir Sitnikov < > > > > >> sitnikov.vladi...@gmail.com > > > > >>> : > > > > >> > > > > >>> Michael> is not proposing to change the > > > > >>> Michael>structure of modules within both projects, merely to have > > the > > > > >> code > > > > >>> for > > > > >>> Michael>both in a single repository. > > > > >>> > > > > >>> I propose to integrate them into a single build, and keep the set > > of > > > > the > > > > >>> published jars. > > > > >>> However, the modules and dependency structure could be kept as is. > > > > >>> > > > > >>> We might want to rename folders like > > > > >>> calcite-core > > > > >>> calcite-linq4j > > > > >>> .. > > > > >>> avatica-core > > > > >>> avatica-server > > > > >>> > > > > >>> However, I am not sure it is that important to discuss folder names > > > > now. > > > > >>> The idea is that as you "open Calcite in IDE, you see both Avatica > > and > > > > >>> Calcite modules" > > > > >>> > > > > >>> Michael>Is there any reason we couldn't have a separate release > > > > schedule > > > > >> if > > > > >>> Michael>both projects are in the same repository? > > > > >>> > > > > >>> A different schedule means Calcite must support at least two > > different > > > > >>> Avatica versions. > > > > >>> In other words, if we allow clients to update Avatica at their > > will, > > > > then > > > > >>> we should allow them building Calcite with different Avatica > > versions, > > > > >>> which implies Calcite test code should succeed for multiple > > different > > > > >>> Avatica vesions. > > > > >>> > > > > >>> That makes it harder to write tests: we have to execute tests with > > two > > > > >>> different Avatica releases (or even more than two). > > > > >>> > > > > >>> There are at least two sources for complexity: > > > > >>> > > > > >>> a) We have to write tests that tolerate multiple versions. For > > > > instance, > > > > >>> "if (avatica.18+) {...}" and so on. > > > > >>> That is not really trivial, especially taking into account some of > > the > > > > >>> tests are created with non-yet-popular > > > > >>> technologies like Quidem where you can't really google solutions. > > So > > > > the > > > > >>> "trivial" task of "making a test to expect two possible outcomes" > > > > >>> becomes less trivial as you try to pass the version from GitHub > > Action > > > > to > > > > >>> Gradle to JUnit to Quidem to no-one-knows-which class. > > > > >>> If we support one Avatica version only, that is not needed. We just > > > > patch > > > > >>> the test in Avatica and Calcite and that is it. > > > > >>> Single repo avoids "Gradle vs Quidem" dance. > > > > >>> > > > > >>> b) If we claim that we support 5 different Guava versions, 3 > > different > > > > >> JDK > > > > >>> versions, 2 different Avatica versions, > > > > >>> then we have to execute 5*3*2 = 30 combinations of the tests. > > > > >>> That is not really a full matrix, however, things get way easier > > if we > > > > >>> support one Avatica version only. > > > > >>> The amount of tests we need to do during a proper release is much > > less, > > > > >> and > > > > >>> it is easier to commit > > > > >>> changes that touch Avatica and Calcite at the same time. > > > > >>> > > > > >>> > > > > >>> Vladimir > > > > >>> > > > > >> > > > > > > > > > >
