GitHub importer fails when duplicate file entries are present in the source but local cloning works

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Importing a project from GitHub is failing with

2:fetch remote: "error: object d544af66177f8e2589a046d440dbf9e150a309b2: duplicateEntries: contains duplicate file entries\nfatal: fsck error in packed object\nfatal: fetch-pack: invalid index-pack output\n": exit status 128.

as shown in the GitLab UI on the Project Import History page.

Performing a local clone from GitHub work completes successfully.

An error is also encountered when there is a very old missing object, when it's not possible to retrieve the missing object from backups or prior clone - this blocks importing the project and all of the project metadata after that.

Steps to reproduce

Example Project

What is the current bug behavior?

Unable to perform the import.

What is the expected correct behavior?

Import the project as much as possible.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

GitLab 14.10

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Is it possible to change the way the import pulls the code from GitHub to be the same as how cloning locally works?

Can we alter the git clone depth, even if temporarily to allow a problematic project to be imported?

A large Premium Customer is unable to migrate and complete the migration to GitLab from GitHub, in ticket ZD - internal links only.