With user contribution and membership mapping, you can assign imported contributions and memberships to users on the
destination instance after import has completed. Unlike the previous method of user contribution and membership mapping,
no preparation is needed before the import.
The process doesn’t rely on email addresses, so you can map contributions for users who have different emails on source
and destination instances.
Each user on the destination instance that is assigned a mapping can:
Explicitly accept
the assignment before any imported contributions are
attributed to them.
You are importing a project from
Gitea
and the user has been deleted on Gitea before the import.
Contributions from these “ghost users” are mapped to the user who imported the project and not to a placeholder user.
You have exceeded your
placeholder user limit
. Contributions from any new users after exceeding your limit are
mapped to a single import user.
If you import the same project twice to the same top-level group on the destination instance, the second import uses
the same placeholder users as the first import.
If you import the same project twice, but to a different top-level group on the destination instance, the second import
creates new placeholder users under that top-level group.
If importing to GitLab.com, placeholder users are limited per top-level group on the destination instance. The limits
differ depending on your plan and seat count. Placeholder users do not count towards license limits.
GitLab.com plan
Number of seats
Placeholder user limit on top-level group
Free and any trial
Any amount
Premium
Premium
101-500
Premium
501 - 1000
Premium
Ultimate and open source
Ultimate and open source
101-500
Ultimate and open source
501 - 1000
Ultimate and open source
Customers on legacy Bronze, Silver, or Gold plans have the corresponding Free, Premium, or Ultimate limits.
For Premium customers trying out Ultimate (Ultimate trial paid customer plan), Premium limits apply.
The above limits are for GitLab.com. Self-managed GitLab has no placeholder limits by default. A self-managed instance administrator can
set a placeholder limit
for their installation.
All the contributions initially assigned to a single placeholder user can only be reassigned to a single active regular
user on the destination instance. The contributions assigned to a single placeholder user cannot be split among multiple
active regular users.
Bot user contributions and memberships on the source instance cannot be reassigned to bot users on the destination instance.
You might choose to keep source bot user contributions
assigned to a placeholder user
.
Users that receive a reassignment request can:
Accept the request
. All contributions and membership previously attributed to the placeholder user are re-attributed
to the accepting user. This process can take a few minutes, depending on the number of contributions.
Reject the request
or report it as spam. This option is available in the reassignment
request email.
In subsequent imports, contributions and memberships that belong to the same source user are automatically mapped to the
user who previously accepted reassignments for that source user.
If the process isn’t complete, contributions still assigned to placeholder users cannot be reassigned to real users and
they stay associated with placeholder users.
Selecting a user for contribution and membership reassignment who already has an
existing inherited membership of the imported group or project can affect how memberships
are reassigned to them.
GitLab does not allow a membership in a child project or group to have a lower role
than an inherited membership. If an imported membership for an assigned user has a lower role
than their existing inherited membership, the imported membership is not reassigned to the user.
This results in their membership for the imported group or project being higher than it was on the source.
Because names and usernames of placeholder users resemble names and usernames of source users, you keep a lot of
historical context.
Remember that if you keep remaining placeholder users as placeholders, you cannot reassign their contributions to
actual users later. Ensure all required reassignments are completed before keeping the remaining placeholder users as
placeholders.
You can keep contributions assigned to placeholder users either one at a time or in bulk.
To keep placeholder users one at a time:
On the left sidebar, select
Search or go to
and find your group.
Select
Manage > Members
.
Select the
Placeholders
tab.
Go to
Awaiting reassignment
sub-tab, where placeholders are listed in a table.
Find placeholder user you want to keep by reviewing
Placeholder user
and
Source
columns.
In
Reassign placeholder to
column, select
Don’t reassign
.
Select
Confirm
.
To keep placeholder users in bulk:
On the left sidebar, select
Search or go to
and find your group.
Select
Manage > Members
.
Select the
Placeholders
tab.
Select
More options icon
next to
Reassign with CSV
.
Search for entries related to RepositoryImportWorker and the correlation ID from Check import status.
Look for fields such as job_status, interrupted_count, and exception.
For GitLab.com (GitLab team members only):
Use Kibana to search the Sidekiq logs with queries like:
Target: pubsub-sidekiq-inf-gprd*
json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: "<CORRELATION_ID>"
json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>"
Look for the same fields as mentioned for self-managed instances.
Identify common issues
Check the information gathered in Review logs against the following common issues:
Interrupted jobs: If you see a high interrupted_count or job_status indicating failure, the import job may have been interrupted multiple times and placed in a dead queue.
S3 connectivity: For imports using S3, check for any S3-related error messages in the logs.
Large repository: If the repository is very large, the import might time out. Consider using Direct transfer in this case.
to fix an error or add an improvement in a merge request. Create an issue
to suggest an improvement to this page.
View pricing
to see all GitLab tiers and features, or to upgrade. Try GitLab for free
with access to all features for 30 days. search the docs.
If you want help with something specific and could use community support,
post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab
subscription). Request support