Hope git-lfs can clone repo without downloading real files.

[PeterDaveHello]

I wonder if is possible?
In fact, git-lfs already made git repo thiner and lighter, I wonder if we can cloning repo without downloading the real files, 'cause the files we want to let git-lfs handle should be binaries or other large and static files, we may not need to edit them all, so if we can just leave them as pointers, I think it'll be awesome! Thanks.

[technoweenie]

Thanks for the idea. This is something we've been kicking around that we're calling "narrow clones." We want a way to specify what paths a user downloads via Git LFS. Right now, it's ALL PATHS. I'm not sure what this will look like yet, though.

[hagenw]

This would be great and I would propose to use NO PATHS as default. The corresponding git repo contains only pointers to the data files and I would suspect to get only those files.
As an example, consider the following workflow (coming from research):

You are a new member to a project and should contribute new data to a common data repo.
In order to push the data you first have to clone the repo, but if the default is set to ALL PATHS this
could mean to download several terabytes of data before you can push your file.

[technoweenie]

I'm not sure we'll change the default, but I want the config to be saved in the repo (like .gitattributes), so admins can set a default workflow for the repo's users.

[hagenw]

That's a good idea as it will be also important for setting the lfs server url.

[technoweenie]

@hagenw You can write a setting to a local .gitconfig file to set lfs.url. Git doesn't look for config files in the working directory, but Git LFS does.

$ git config -f .gitconfig lfs.url abc

We should probably explain this better in the docs.

[andyneff]

@technoweenie Does this help cloning when I have a different url for git repo and lfs.url?

The only thing I have found that works is

git clone -n {my_repo}
git config lfs.url abc
git checkout master

But

git config -f .gitconfig lfs.url abc
git clone /dev/shm/local.git 

Still errors with "fatal: destination path '.' already exists and is not an empty directory." on git version 2.4.0

[technoweenie]

@andyneff The .gitconfig file should live in the root of your repository. Then any user can clone it without worrying about what it's set to. Any git config settings overwrite any settings from that .gitconfig file.

The error message looks like a git clone message and unrelated to Git LFS. Are you sure you're cloning to a new directory?

[andyneff]

I was doing it backwards (I didn't make .gitconfig part of the repo. I was trying to clone into a directory containing .gitconfig which I knew felt wrong). I see what you are saying now. Works perfectly! Thanks @technoweenie

[savinov]

git-annex works this way: when you clone repository, you get only symlinks to the unexisted real files, then you get all the needed binary files

As for Git LFS, I found only this workaround: do not push .gitattributes to the repository. In that case when repository is cloned, you get only links to real files, and then you may get it with git lfs pull, but when you get the real files, Git will treat it as a file replacement.

IMHO this is important LFS drawback comparing to git-annex, I hope it will be resolved

[technoweenie]

You have a couple options now as of Git LFS v1.1:

• Install with the skip-smudge option (man page).
• Configure the lfs.fetchinclude or lfs.fetchexclude git config values for file paths that are always downloaded or always ignored. (man page).

[grantstephens]

I'm sorry to drag this up again, but I don't think this solves the problem. Say I have a repo and I want its default behavior to be not to download the files when cloned, even if git lfs is installed- how do I do that? I'm guessing that there would have to be a file in the repo itself to tell git lfs to not download the files or be part of the .gitattibutes file?
Use case: I have a repo that I used pip install on which indirectly clones the repo to a temporary directory while it is installed- I don't necessarily want the data files used for testing to be downloaded if the tests aren't going to be run.

[grantstephens]

Sorry, figured it out. For completeness- if you want to not have the repo auto get everything you have to add a .lfsconfig file in the repo with fetchexclude=*
You can then get the files using git fetch --all

[ttaylorr]

Sorry, figured it out. For completeness- if you want to not have the repo auto get everything you have to add a .lfsconfig file in the repo with fetchexclude=*

You can also run any of the LFS "download" commands (clone, pull, fetch) with the -X flag and a pattern of files to exclude. Similarly, the -I flag accepts a glob of files to include.

More information about this can be found in the manpages.

[mitar]

It seems git lfs clone has been removed in recent versions, so approach with -X does not work anymore?

(Edit: It seems I used a too old version of git, not too new.)

[bk2204]

git lfs clone is still present in the latest versions. With newer versions of Git, it's deprecated in favor of git clone, but it's still present.

[ttaylorr]

`git lfs clone` is still present in the latest versions.

Right, and eventually (as brian notes) we'll remove 'git lfs clone' entirely and encourage users to use 'git clone' instead. To emulate the `-X` (or '--exclude') behavior from 'git lfs clone' in 'git clone', you have a couple of options: - Set 'GIT_LFS_SKIP_SMUDGE=1' in your environment, to skip the "smudging" process entirely. This means that 'GIT_LFS_SKIP_SMUDGE=1 git clone ...' is behaviorally equivalent to 'git lfs clone --exclude="*" ...'. - Set 'lfs.fetchexclude' in your Git configuration to be a comma- separated list of patterns to exclude. This means that 'git -c "lfs.fetchexclude=*" clone ...' is behaviorally equivalent to 'git lfs clone --exclude="*" .' It also has the benefit of being able to set more (1) fine grained patterns, and (2) _also_ set `lfs.fetchinclude`, which corresponds to '--include'.