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 <[email protected]> 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 > [email protected] > > Le mer. 10 nov. 2021 à 06:47, Dmitry Sysolyatin > <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > 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 <[email protected]> > wrote: > > > > > > > >> +1 for a single repo. > > > >> > > > >> Вт, 9 нояб. 2021 г. в 19:22, Vladimir Sitnikov < > > > >> [email protected] > > > >>> : > > > >> > > > >>> 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 > > > >>> > > > >> > > > > > > >
