Migrating forked repositories to Bitbucket mesh fails in Bitbucket Data Center
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When trying to migrate forked repositories to mesh in Bitbucket Data Center, the migration fails with the error "unable to normalize alternate object path.".
Environment
Bitbucket 8.x.x
The environment can be newly deployed on Kubernetes, and the forks could be created before moving to Kubernetes.
Diagnosis
The repository getting migrated is a fork of another repository, and the parent repository could have already been migrated successfully or deleted. You can see an error below in the atlassian-bitbucket.log for the error.
1
2
023-10-27 14:54:02,260 WARN [dc-migration:thread-2] ICON0213 *YJSIBRx808x344x0 vfm98j 193.117.227.202 "POST /rest/api/latest/migration/mesh HTTP/1.1" c.a.s.i.m.DefaultMeshMigrationService [~TEST/test-repo[2]] Migration failed. Attempting to reset the hierarchy and retrying...
com.atlassian.bitbucket.scm.CommandFailedException: 'git ls-remote -q .' exited with code 0 saying: error: unable to normalize alternate object path: /var/atlassian/application-data/bitbucket/shared/data/repositories/1/objectsCause
While deploying Bitbucket on Kubernetes, there is a possibility that the shared home mount would have been mounted somewhere outside of Bitbucket.
For example:
1
2
3
Mounts:
/var/atlassian/application-data/bitbucket from local-home (rw)
/var/atlassian/application-data/shared-home from shared-home (rw)While creating a fork, Bitbucket doesn't make a copy of the data in the child repository. Instead, it creates a file called alternates and mentions the path of the parent repository inside that. The alternate is created by the git clone --shared command. So, the path that gets created in the alternate path is an absolute one. folder
To illustrate this better, consider an install where $BITBUCKET_HOME is set to/var/atlassian/application-data/bitbucket. So Bitbucket expects the parent repositories of the forks to be available in /var/atlassian/application-data/bitbucket/shared/data/repositories the folder. But here, in the example above, the shared home path is set as /var/atlassian/application-data/shared-home . So, the repositories will be available in the path /var/atlassian/application-data/shared-home/data/repositories.
As a result, the fork would become "corrupted", because it would no longer be able to access borrowed objects.
Solution
From UI, take the repository slug and find the ID of the repository. You can find it from the Repository Settings > Location or go to the Bitbucket database and run the query below.
1select * from repository where slug = 'repository-slug'Go to the repository's location in the file system and inside folder objects. For example
/var/atlassian/application-data/shared-home/data/repositories/<repo-id>/objectsCorrect the alternates file to point to the right path for the parent repository.
Was this helpful?