Our git repo structure is currently that we have a main repo crm that pulls in a submodule repo crm\civicrm
What we would like to do is
- remove the code that specifically checks out the civicrm repo in our CI build - we need Releng to do that
- remove the submodule from our crm repo and commit the civicrm folder directly into the repo - we can do this - but it needs to be in co-ordination with ^^
- archive the crm\civicrm repo
Technically this should be easy but it involves a step we can do to be co-ordinated with a step we don't have permission to do.
Our goal with the civicrm repo is to be running the 'stock' upstream monthly release and we very actively upstream to that end. That means we are not terribly interested in the history of our repo - only what patches we have left to upstream. The way we manage the crm\civicrm repo is that each new release we unzip the tarball of code into it and re-apply any patches that we deem necessary. Although the repo has a long history we effectively reset it every time we deploy a release and never look back further. The upstream repo DOES have a a git repo - but it doesn't actually match the structure of our repo - so having the repo is not helping us wrangle patches, either
However, having the separate repo does actively hurt us - because our WMF crm code interacts with the CiviCRM code in multiple ways we wind up putting in a lot of work to adapt our crm code such that it will work with the new civicrm code AND the existing code. Then we upgrade CiviCRM and then have to remove the temporary compatibility patches. Or, we do similar within CiviCRM - two of the five patches we are currently carrying in the crm\civicrm repo were in order to keep CI passing as we last upgraded. (I hope to be rid of the remaining three very soon after we get rid of the submodule as one of them will be easily fixable once that is done)