Michael's latter suggestion is what I was thinking about :) I've gone ahead and put in the request for an Avatica repo. We can do whatever we want with it then.
On Mon, Mar 20, 2017 at 6:11 PM, <[email protected]> wrote: > You can use git subtree split to extract the Avatica commits into a new > repository. This would maintain the history but would generate new commit > IDs. Alternatively the history could start with the entire Calcite history > with the first commit being one which deletes all non-Avatica files. > > -- > Michael Mior > [email protected] > > From: Julian Hyde > Sent: Monday, March 20, 2017 18:09 > To: [email protected] > Subject: Re: Commits during release vote > > I’m not sure what are the options for splitting a git repo. Do you think that > the avatica repo will retain the commit ids of the current repo? (Presumably > to do that we need to keep all of the calcite commits, then delete the > calcite files.) Or do you think the new repo should start from an empty > history and contain only avatica commits? > > I’ve logged https://issues.apache.org/jira/browse/CALCITE-1717 > <https://issues.apache.org/jira/browse/CALCITE-1717> to track. > > We could also consider, at some point, asking for an AVATICA prefix for JIRA > cases. > > Julian > >> On Mar 20, 2017, at 2:12 PM, Josh Elser <[email protected]> wrote: >> >> How fitting :) >> >> It should be fairly simple -- let me put in a request to infra. Once we have >> a repo, it should be self-service for us to move the stuff over there. >> >> Julian Hyde wrote: >>> Thanks - I’ll rebase after the release. >>> >>> I’m sitting in a cafe right now and there’s a guy right outside the window >>> re-potting the plant pots: pull up each plant individually, pull its roots >>> apart from other plants, and put into a new pot with more room around it to >>> grow. >>> >>> We should definitely do that with Calcite/Avatica. If someone has the time >>> and energy to move Avatica into a separate repo I will support that. >>> >>> Julian >>> >>> >>>> On Mar 20, 2017, at 9:34 AM, Josh Elser<[email protected]> wrote: >>>> >>>> Oops, sorry for causing some pain, Julian. I'm ok with a >>>> rebase/force-push. It completely slipped my mind that I should have held >>>> off on those commits :) >>>> >>>> I still think separating out Avatica from the Calcite repo would be better >>>> long term (Shi had gotten confused over this, recently), but, like you >>>> said, it's a pretty minor thing. >>>> >>>> Julian Hyde wrote: >>>>> Josh, >>>>> >>>>> I see you made 3 commits to Calcite’s master branch yesterday to fix >>>>> Avatica issues. There is a release vote for Calcite underway, and the >>>>> last few changes for that are in branch-1.12 but not in master. Up to >>>>> this point we have been able to keep the commit tree linear (i.e. there >>>>> are no merge commits with two parents), and I would like to retain that. >>>>> >>>>> To keep the tree linear, I will need to rebase master onto branch-1.12 >>>>> after the release, then do a force push to master. Is that OK with you? >>>>> >>>>> Devs, >>>>> >>>>> Going forward, there are several solutions (lock the repository during >>>>> release votes, force push to master after a a release, and allow the >>>>> repository to have merge commits). And splitting the Calcite and Avatica >>>>> repositories would at least allow Avatica development to continue during >>>>> Calcite release votes. We should discuss the various options. But in my >>>>> opinion, we are still small enough that the current policy (pausing >>>>> commits during release votes, to keep a linear release history) is >>>>> working fine. >>>>> >>>>> Julian >>>>> >>> > >
