You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Maybe you have similar issues like this reported on Github, which doesn't support pushing LFS objects to public fork https://stackoverflow.com/questions/64400301/got-stuck-while-uploading-in-public-repository-in-github-via-git.
I don't know your use case, but if you want to do backups for your repos and metadata, you could automate it with dedicated apps on Bitbucket marketplace https://marketplace.atlassian.com/apps/1225728/gitprotect-io-backup-for-bitbucket.
I guess there should be "better" ways to do this, but whenever I've migrated LFS objects between repositories in GitHub or Bitbucket, I followed this procedure:
If you are handy with the command line, this should all not be too hard to do without looking at individual files.
To be really thorough, you can replace all of the files in the entire history, but it's more complicated and I honestly never felt the need.
Thank you, Benjamin. I would like to know about the last step in more detail.
I have discovered and have all those LFS objects in my local. The repository is migrated without LFS. (When I clone this new one without LFS it gives me an error for object not found). So how do I restore all the LFS files to the new repo?
Can you clone the new repo, even if lfs is throwing errors? Otherwise you'll need to clone explicitly without lfs. The LFS files will exist, but only as tiny text files. Then you'll have to delete all those files and commit that so that everything is 'fine' to git on that branch in the repository. Then you copy-paste the correct files back into the repo and push them as new files in a new commit. Now they should be uploaded correctly to the LFS of the new repo.
If the feature branch doesn't have new files or changes to existing files, they should be able to merge the new LFS files from the main branch without issues.
If the feature branch has some changes to and/or new LFS files, I'd migrate those files exactly like you did on main. Then merge main into the branch. Conflicts will pop up for all files that were changed on the branch, but those can be resolved simply by taking the version of the branch.
Yes, that's not the kind of repo I've been working with. 250 LFS files shouldn't be a problem, but 2000 branches is a lot! I'd probably write a bash script that performs the conversion on each branch automatically, but I guess that would still cause some issues further down the line when merging branches.
Maybe look into the stuff from the other comment in this thread.
Edit: and contact Bitbucket support directly.