Because git commit information is independent of GitLab user information, there's no reliable way to do this -- at least not retroactively or with 100% accuracy/certainty in every circumstance.
For example, a user can easily create a commit with an author/committer name/email that simply does not exist.
git config --local user.name "A fictitious name"
git config --local user.email "nonexistant@example.com"
git commit -m "you cant find me"
git push # works fine
However, you may be able to make this lookup and association more reliable by one or more methods.
Push rule to ensure committer email is a GitLab user
A push rule can be setup using the predefined push rule "Check whether the commit author is a GitLab user" which will make sure that the author email matches the email of an active GitLab user.
This would make mapping commits back to GitLab users more reliable because the author email has to be a valid/active GitLab user.
The same example above would fail to push due to this rule. However, over time, a user may change their email and that will lead to a similar issue you're experiencing today.
Requiring GPG signatures for all commits
Similar to the "Check whether the commit author is a GitLab user" push rule, another possible way to make this association more reliable would be to require verified commits (GPG signing) for all commits using the "reject unverified commits" push rule. That way, you can more readily rely on the signature information to relate it back to a particular user.
If a commit is verified, that means that the commit is (1) signed using a GPG key, (2) that GPG key email matches a verified email for the GitLab User, and (3) the commit email matches the GPG key email.
Additionally, the GPG signature will contain the username and email in the signature itself.
for c in self.project.commits.list(as_list=False)
signature = c.signature() # the commit needs to be signed for this to work
print(c,
'was authored by',
signature['gpg_key_user_name'],
signature['gpg_key_user_email']
)
This is essentially the same information shown in the GitLab UI for a verified commit:
Cross-referencing against the user API
With either of the two approaches described above, the commit information (committer email or GPG key ID) could further be cross-referenced against the users API. For example, if a committer is still an active GitLab user, you can use the API to find every user's email addresses or GPG keys and cross-reference them with the commit information.
Of course, this will only apply to commits/projects created after the commit signing rule is established. You can't retroactively create this information for existing commits. Some other caveats apply.
Because information provided by the user API can change over time (emails and GPG keys can be added/removed over time or users can be deleted from GitLab altogether) it should stand to reason that this it will not always be possible to obtain the GitLab User ID from a particular commit in every scenario.
The only way to reconcile changes in such cases would be to audit changing state over time (e.g. by referring to GitLab server logs or audit logs on self-managed instances).
