I think if you rebase “site” onto “master”, git will spot commits that are already on “site”.
$ git checkout site $ git rebase -i origin master All being well, site should end up identical to master after the rebase. So force-push is not scary. Julian > On Apr 25, 2018, at 11:31 AM, Michael Mior <[email protected]> wrote: > > Sure, I understand. But no one can do a fast-forward merge to the site > branch unless they know for sure that nothing in there is going to make > changes to the site that shouldn't be deployed. And then we're back to > whoever updates the site needing to already know what should be deployed. > > I'm suggesting the following: > > 1. During development, cherry pick *only* commits which affect the site > from `master` to `site` > 2. At release time, force push the `master` branch to `site`. > Unfortunately, this means if someone does mistakenly make site changes > directly to the `site` branch, then these will be lost. I don't see an easy > way of preventing this. > > -- > Michael Mior > [email protected] > > 2018-04-25 14:25 GMT-04:00 Julian Hyde <[email protected]>: > >> Well, consider the current “master” and “site” branches[1]. They were in >> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], which >> had changes to the site related to product features, so “master” and “site” >> had to diverge. >> >> It isn’t always possible for “master” and “site” to be on the same path, >> but for this release, it was until just before CALCITE-2045. >> >> Julian >> >> [1] https://github.com/apache/calcite/network <https://github.com/apache/ >> calcite/network> >> >> [2] https://github.com/apache/calcite/commit/ >> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/ >> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a> >> >> [3] https://github.com/apache/calcite/commit/ >> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/ >> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c> >> >> >> >>> On Apr 25, 2018, at 11:16 AM, Michael Mior <[email protected]> wrote: >>> >>> I don't see how the sync with the master branch could be a fast-forward >>> merge. This isn't possible if commits just affecting the site have been >>> cherry picked since the last sync. >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>> 2018-04-25 14:13 GMT-04:00 Julian Hyde <[email protected]>: >>> >>>> My personal opinion about (non-fast-forward) merge commits: never do >> them. >>>> >>>> If site and master can be on the same line (i.e. if there is no new >>>> product-related changes to the site) then they should be. >>>> >>>> If they need to diverge, then cherry-pick individual commits from master >>>> to site. >>>> >>>> I added some instructions at the end of https://github.com/apache/ >>>> calcite/blob/master/site/README.md <https://github.com/apache/ >>>> calcite/blob/master/site/README.md>. >>>> >>>> Julian >>>> >>>> >>>> >>>>> On Apr 25, 2018, at 11:06 AM, Michael Mior <[email protected]> wrote: >>>>> >>>>> Sure. Although there (at least) two ways of syncing site with master. >> One >>>>> being to force push master to the site branch and the other to merge >> the >>>>> master branch into site. I do kind of like the idea of the force push >>>> just >>>>> to avoid having the site branch be eternally filled with a bunch of >> merge >>>>> commits. >>>>> >>>>> One thing that didn't immediately occur to me is what happens with the >>>>> Javadoc? >>>>> >>>>> -- >>>>> Michael Mior >>>>> [email protected] >>>>> >>>>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <[email protected]>: >>>>> >>>>>> A force-push to the “site” branch each release would not be a terrible >>>>>> thing. (Force-pushes are only suspect when they are to the master >>>> branch or >>>>>> a release branch.) Before the release, the release manager should make >>>> sure >>>>>> that edits on “site" have made it to “master”. Right after the >> release, >>>>>> they will deploy the site from the “site” branch, which almost >> certainly >>>>>> means syncing “site" with “master”. >>>>>> >>>>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <[email protected]> >> wrote: >>>>>>> >>>>>>> Sounds reasonable to me. I like that better than the current approach >>>> of >>>>>>> whoever is updating the site needing to maintain mental state on what >>>> is >>>>>>> and isn't ready to be posted. We should of course add documentation >> for >>>>>>> this as part of the release process. We also should make clear in the >>>>>> site >>>>>>> documentation that nothing should be committed to the site branch >>>>>> directly, >>>>>>> but only what is cherry picked from master. I might even suggest that >>>> the >>>>>>> sync which happens during release be a force push of the current >> master >>>>>> to >>>>>>> the site branch, but I'm not sure I like that idea. >>>>>>> >>>>>>> -- >>>>>>> Michael Mior >>>>>>> [email protected] >>>>>>> >>>>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <[email protected]>: >>>>>>> >>>>>>>> I am adding Kevin to the committers list, and I am seeing the >> problem >>>> of >>>>>>>> mixed changes - recently Michael has edited the site to add two PMC >>>>>>>> members, and Shuyi has added documentation for CREATE TYPE. We want >>>> the >>>>>>>> former to appear on the site, but the latter should wait until the >>>>>> release. >>>>>>>> >>>>>>>> I propose to create a “site” git branch that cherry-picks changes >> that >>>>>> we >>>>>>>> wish to have appear on the site immediately. >>>>>>>> >>>>>>>> On each release, it would be in sync with master, but might start to >>>>>>>> differ when we add documentation for features. It would sync up on >> the >>>>>> next >>>>>>>> release. >>>>>>>> >>>>>>>> Any comments/objections? >>>>>>>> >>>>>>>> Julian >>>>>>>> >>>>>>>> >>>>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <[email protected]> >> wrote: >>>>>>>>> >>>>>>>>> You are right. Thanks a lot for the explanation, Julian. >>>>>>>>> >>>>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <[email protected]> >>>>>> wrote: >>>>>>>>> >>>>>>>>>> I think it’s misleading to end-users if the web site contains >>>> features >>>>>>>>>> that have not yet been released. So, we aim to re-generate the web >>>>>> site >>>>>>>>>> just after a release. (For non product-related stuff, such as >>>>>> committers >>>>>>>>>> and upcoming talks, we change the web site continuously. The >> person >>>>>>>>>> maintaining the web site has to be a bit careful not to publish >> the >>>>>>>> wrong >>>>>>>>>> stuff.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <[email protected]> >>>> wrote: >>>>>>>>>>> >>>>>>>>>>> @Julian, thanks for reviewing the code. I think we need to >>>> regenerate >>>>>>>> the >>>>>>>>>>> website as well so that it contains the latest documentation on >>>> type >>>>>>>>>>> collection and type DDLs. Let me know how I can help. >>>>>>>>>>> >>>>>>>>>>> @Valli, with the latest master, you should be able to either use >>>>>> CREATE >>>>>>>>>>> TYPE statement to define your own type or define your new type in >>>> the >>>>>>>>>> JSON >>>>>>>>>>> schema. >>>>>>>>>>> >>>>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <[email protected] >>> >>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need >>>>>> anything. >>>>>>>>>>>> >>>>>>>>>>>> shuyi >>>>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <[email protected]> >>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry >>>> Shuyi) >>>>>>>> but >>>>>>>>>> I >>>>>>>>>>>>> reviewed it yesterday and am currently testing, so it should be >>>>>>>>>> committed >>>>>>>>>>>>> to master shortly. >>>>>>>>>>>>> >>>>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <[email protected]> >>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently, user defined type is not supported in Calcite. But >>>> it's >>>>>>>>>> WIP, >>>>>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045 >> . >>>>>> With >>>>>>>>>>>>> this >>>>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your >> own >>>>>> type >>>>>>>>>> or >>>>>>>>>>>>>> define your new type in the JSON schema. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Shuyi >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai < >>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'. >>>> For >>>>>>>>>>>>>>> example, select >>>>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is >>>>>>>> showing, >>>>>>>>>>>>>>> Unknown data type name 'TEXT'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How can I make calcite to parse the above query successfully >>>>>> having >>>>>>>>>>>>>>> user-defined data type 'text'? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks in advance >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> "So you have to trust that the dots will somehow connect in >> your >>>>>>>>>>>>> future." >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> "So you have to trust that the dots will somehow connect in your >>>>>>>>>> future." >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> "So you have to trust that the dots will somehow connect in your >>>>>>>> future." >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> "So you have to trust that the dots will somehow connect in your >>>>>> future." >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
