How to specify where Git LFS files will be stored?

Question

I was just wondering if anyone could clear up some confusion I have about using Git Large File Storage.

When creating your new repository, I know how to track certain files with git lfs track, but how do you specify where those files will be stored?

For example, in the project I am working on there are a number of png and wav files. These are being tracked using git lfs track. The Git LFS website says that they are stored on a remote server, but I cannot find out where that information is in our repository.

In addition, when a second user clones the repo, the project contains only pointers to the LFS objects. How can they find/use the url for the remote where the actual files are stored?

(We are using Bitbucket and a local system git for our repo.)

Answer 1

The Git Lfs website says that they are stored on a remote server, but I cannot find out where that information is in our repository.

They're not stored in the repository, at least in a technical sense. git-lfs adds a second area, the large file storage area, which is a peer of your repository. The large files are stored there.

I would have expected BitBucket to present this information in a meaningful way on their website.

In addition, when a second user clones the repo, the project contains only pointers to the LFS objects.

They need to install git-lfs. That is the program responsible for downloading and uploading the large file content.

Answer 2

The Git-LFS storage server is specified by the lfs.url property, for example:

git config lfs.url https://github.com/foo/bar.git/info/lfs

The default (when lfs.url is unset) is to derive the Git-LFS server URL from the URL of the remote using some heuristics like: [email protected]:foo/bar.git -> https://github.com/foo/bar.git/info/lfs

You can view the current server for each remote with:

git lfs env | grep Endpoint

Note: current git-lfs (2.13.3) supports only HTTP/HTTPS and file:// endpoint protocols, so you can't push LFS objects to a remote clone over SSH, for example. A workaround is to mount the remote repository over sshfs and use file://.