Current limitations for Git LFS with Bitbucket

Currently, the transfer of repositories with Git LFS files is disabled.

Transferring a repo does not give the new owner permissions to access the Git LFS files, so all references to those files in the repository become broken. Furthermore, some metadata, such as for issues and pull requests, are not correctly transferred to the new repo.

Once any user pushes the first LFS file to the repo, then transferring of that repo is disabled.

Instead of transferring the repo, you can clone the repo to your local machine, then create a repo in Bitbucket, and push to that.

When you do this, all files and the Git history will be available in the new repo, but the metadata for such things as issues, pull requests won't be copied over. Furthermore, you'll have to set up users and access permissions for the new repo.

Proceed as follows:

1. Clone the Git LFS repo to your local machine as usual:

2. Fetch the Git LFS history:

   1 git lfs fetch --all origin

3. Create a new repo in Bitbucket. 

4. Add a remote locally that points to the new repo:

   1 git remote add new-origin <URL to new repo>

5. Now push to the new repo:
   

   1 git push -u new-origin --all

   This pushes the repo and its refs for the first time.

6. Push Git LFS data to the new repo:

   1 git lfs push --all new-origin

7. Finally, update the remotes for the new repo:
   

   1 2 git remote set-url origin <URL to new repo> git remote set-url --push origin <URL to new repo>

    

Currently, when you fork a repo that has Git LFS files, the LFS files are not copied to a new remote store.

Forking a repo that has Git LFS files copies all files to the fork as usual, including the LFS pointer files. However, the pointer files still point to the original remote store, but the new repo doesn't have permissions to access that.

Once any user pushes the first Git LFS file to the repo, then this limitation applies to forking of that repo.

Note that cross-fork pull requests are affected, for the same reason – LFS files are not copied to the remote store when the pull request is merged.

When you fork a repo, you can use the command line to transfer the Git LFS files to the new repo, as follows:

1. Fork the repo as usual in Bitbucket.

2. Now, clone the new repo to your local machine:

   1 git clone <clone URL for forked repo>

   You're may to see errors – we're going to fix those below.

3. Add a remote that points to the original repo:

   1 git remote add old-origin <URL to original repo>

4. Fetch the Git LFS data from the original repo:

   1 git lfs fetch --all old-origin

5. Push the Git LFS data to the new repo:

   1 git lfs push --all origin

6.  Pull from the new repo to update the clone:

   1 git lfs pull

   You're done!

Currently, Git LFS files are not included when you download an archive of a repository, tag or branch. Other than the usual source files, only the pointer reference files for LFS files are included. This means that archiving does not create a full backup for you.

Although the Git LFS pointer files are included in the archive, the LFS files are not currently added.

Once any user pushes the first LFS file to the repo, then this limitation applies to archives made of that repo.

The workaround is to manually clone the repo and archive it locally:

1. Clone the repo:

   1 git clone <URL for repo>

2. Manually archive the repo directory locally using your favorite tool.

3. (Optional) Upload the archive to the Downloads page in Bitbucket.

Note that doing this will only archive the files currently in the head of the main branch. To get all the LFS files ever referenced in the Git history you'll need to use git fetch --all before creating the archive.

 The workaround is to manually clone the repo, check out the branch, then archive it locally:

1. Clone the repo:

   1 git clone <URL for repo>

2. Check out the branch:

   1 git checkout <branch_name>

3. Manually archive the repo directory locally using your favorite tool.

4. (Optional) Upload the archive to the Downloads page in Bitbucket.

 The workaround is to manually clone the repo, check out the tag, then archive it locally:

1. Clone the repo:

   1 git clone <URL for repo>

2. Check out the tag:

   1 git checkout tags/<tag_name>

3. Manually archive the repo directory locally using your favorite tool.

4. (Optional) Upload the archive to the Downloads page in Bitbucket.