I don’t think killing the history is a good idea at all, and I’m not sure what infra would think about it. Perhaps you could suggest that cloning with depth 1 would be appropriate?
Personally I think that having a separate camel-site repo with just the published site with all history would make even more sense. David Jencks > On Nov 2, 2020, at 4:04 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > Hi Zoran > > Yeah its fine with me. > > On Mon, Nov 2, 2020 at 1:00 PM Zoran Regvart <zo...@regvart.com> wrote: >> >> Hi Cameleers, >> when cloned the camel-website repository is 1.3GB in size. I think >> that's because of the large number of commits in the `asf-site` >> branch. As a reminder when we build the website, to publish it we have >> to push the resulting files to the `asf-site` branch. >> >> I think it would help if we were to squash to commits there. This >> would, of course, mean we would lose the history on that branch. >> >> I was thinking we would keep the last 10 commits unsquashed, and >> squash all older commits (apart from the initial one), with something >> like: >> >> git -c core.editor="sed -i 2,/$(git log --skip=10 -1 >> --pretty=format:%h)/s/^pick/squash/" rebase --interactive >> 1586f65bf7f24784dc99e22aff08e44c7dbb1920 >> >> That `sed` would skip the first line and replace until the 11th commit >> (hash printed by that `git log`) has been seen all "pick" with >> "squash". >> >> I'd put this as a step in the deploy part of the pipeline[1]. >> >> WDYT? >> >> zoran >> >> [1] >> https://github.com/apache/camel-website/blob/8cafa694e13b72d3013b7de2b956da73f55ca2b4/Jenkinsfile#L89 >> -- >> Zoran Regvart > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
