This is one of the Code walkthrough I wrote while exploring the Gitea codebase.
Linking Gitea accounts with accounts on other forges
After creating a user on a Gitea instance, it is possible to link it with an account that exists on another forge such as Gitlab.
The password of the Gitea user is needed to complete the operation.
And the Security tab of the User settings page will display a reminder about the established link.
The next time the user wants to login, they will have the option to use either the Gitea user and password or click on the GitLab icon: both will work until the link is removed.
Migrations and linked accounts
Once an account on GitLab.com is linked to a Gitea instance, migrating a project from GitLab…
… will know the user that exists on GitLab.com is the same as the user on the Gitea instance.
External user remapping during migration
When an issue is imported, the PosterID field is looked up in the list of external users. If found, it is used as the author of the issue. If not found, the user doing the migration is made the author if the issue instead. But the PosterID and PosterName fields are preserved in the issue table, in case a link becomes available at a later time.
A similar logic is applied to other migrated elements such as releases, reviews, comments, etc.
Asynchronous external user remapping
A daily cron job runs the UpdateMigrationPosterID function which loops over the ExternalUser table and calls the UpdateMigrationsByType function. It will look for rows in the issue, comment, review, etc. tables where the OriginalAuthorId field matches the external user. If one is found, it means the actual author was not found at the time of the migration and the user doing the migration was used instead. Since the author is now known, it is substituted and the OriginalAuthorID and OriginalAuthor fields are cleared.