The only differences in persistent data outside of the repository between hg-git based and native Mercurial repositories are the commit hashes and the `vcs_type` field. While the latter is very easy to update, there are many places that reference commit hashes in the database: - [x] Issues and Merge Requests: `description` and `title` columns and their `_html` derivatives (stored renderings) - [x] Comments on Issues, Merge Requests and other (common model that's called Note) - [x] Merge Requests: several `_sha` columns in `merge_requests` and `merge_request_diffs` - [x] Diff cache on filesystem or object storage (hoping a simple invalidation would be enough) - [x] Releases: `sha` column, or tag (fallback if no sha) Mandatory tasks for the repository itself: - [x] #500 ensure default GitLab branch file - [x] ensure all refs from Git using the command provided by py-heptapod!52. See also #431 Entry points - [x] library module or class - [x] rake task to migrate one project, as idempotent as possible, with a `FORCE` option to re-run on an already migrated repo. The list of direct Git SHA references will probably have to grow when we start digging into this for good. There are many columns named `sha` in the database schema. I currently count 35 of them with a crude search: ``` grep -E 'sha[1|2 ].*(bytea|char|text)' structure.sql | wc -l 35 ``` Also, there is an ActiveRecord `sha` attribute type, backed by binary (`bytea`) columns. Systematic search for this type could give us more hits. Work can start in the Heptapod 0.20.0 time frame, but it's likely to be complete only afterwards.