Comments inline. Le mar. 2 juil. 2019 à 16:17, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> a écrit : > > Micael>How so? Just delete the branch or rebase to delete the commits. I > fail > to see the complexity here. > > The complexity is not technical. It is INFRA who prohibits rebases. > That is why I suggest we don't put "build artifacts" into the main source > repositories. > In the worst case we just throw away "preview repo". > > Here is a recent relevant INFRA ticket: > https://issues.apache.org/jira/browse/INFRA-18499?focusedCommentId=16865680&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16865680 > > TL;DR there was <<history overwrite in Apache source repositories requires " > vp-in...@apache.org or our infra admin escalation">> > They denied to remove third-party jar files from the repository (e.g. > lib/js_rhino1_6R5.jar), and I did not escalate that because, well, I don't > want spend time there. >
We regularly force push to the Calcite repo, so this is not a restriction we face. That said, I don't have any major problems with creating a separate repo. > Michael>Why do we need both to be in the same repository if we're just > using it for testing? > > I just assume they both could share some resources (e.g. css? images?) and > have cross-links (e.g. Calcite site points to Avatica pages). > So I thought it would be just simpler to put everything into a single repo > so it looks closer to the production site. > > Do you suggest to have different "test" sites for Calcite and Avatica? > The two repos are already separate so I don't think this is a big departure. As above though, I'm not strictly opposed to a separate repo. > Michael>With GitHub pages, published content is stored on a > Michael>separate gh-pages branch. > > I'm used to `git clone https://github.com/organization/repo.git` > It clones all the branches and tags. > Apparently gp-pages would be there as well. > Do you think everybody is cloning git repositories in a different way? > My mistake, this is a fair concern. > Vladimir
