Skip to content

Default system gitconfig skips LFS download #2321

Closed
@mcfandw

Description

@mcfandw
  • I was not able to find an open or closed issue matching what I'm seeing

Reference #2140

Setup

  • Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
$ git --version --build-options
git version 2.23.0.windows.1
cpu: x86_64
built from commit: 4db2e5cc9e1522131a039cbad3970f147a39f0ce
sizeof-long: 4
sizeof-size_t: 8

  • Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
    I've seen the same behavior on Windows 7 (64-bit) and Windows 10 (64-bit).
$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]
  • What options did you set as part of the installation? Or did you choose the
    defaults?
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Interactive Add: Enabled

  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

I first encountered this with git installed on my computers (tried multiple, Windows 7, Windows 10, etc.). I then found that the portable version of git exhibited the same thing, so that is probably an easier environment to reference, because it eliminates the variability of the installed configuration.

Details

  • Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

git clone <url>
  • What did you expect to occur after running these commands?

In the past, I did "git clone " on a repository (hosted on Bitbucket in this case) which had LFS enabled, and git would download all the LFS binaries during the clone. As of version 2.23, it no longer downloads the LFS binaries when I clone the repository. Comparing portable git v2.23 with previous versions, I tracked the change in behavior to these settings in the --system config:

(mingw64/etc/gitconfig)

[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge --skip -- %f
	process = git-lfs filter-process --skip
	required = true

I confirmed that these are the settings active in my environment with:

$ git lfs env
git-lfs/2.8.0 (GitHub; windows amd64; go 1.12.2; git 30af66bb)
git version 2.23.0.windows.1
...
GIT_EXEC_PATH=C:/Program Files/Git/mingw64/libexec/git-core
git config filter.lfs.process = "git-lfs filter-process --skip"
git config filter.lfs.smudge = "git-lfs smudge --skip -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

I found that in prior versions the --skip flag was not present in this file. Eventually I stumbled across #2140 and 047ff72c3bbd74336321a279d585b72fb5c069ad, which appears to be when the --skip flag was added to the default settings. I found that by removing the --skip flag, or overriding these settings in my global gitconfig, git went back to the behavior I took for granted (automatically downloading the LFS binaries).
I see these same settings when I install git or use portable git, on multiple computers, so I don't think my system is broken. These settings appear to be what you get when you give LFS the --skip-smudge flag, and the documentation appears to confirm the behavior I see:

An additional option of --skip-smudge can be added to skip automatic downloading of objects on clone or pull. This requires a manual git lfs pull every time a new commit is checked out on your repository.

Can someone help me understand why these are the default settings? Is there an expectation that users should be doing more setup and configuration when dealing with LFS? (Like running git lfs fetch, git lfs pull or setting your own gitconfig settings to not include the --skip flag.) Like I said, I previously took for granted that everything just "worked" without any configuration or setup. Or is there something wrong with my repositories? (We have several that are similar, and this happens on all of them.)
I'm not an expert on LFS, so I'm struggling to understand how the settings affect things and why the defaults changed. I don't understand why they changed, but also don't know enough to claim they shouldn't have changed. Once I figured out what was going on, it wasn't difficult to change the behavior on my system. However, I've got a whole team of people using git on a repository with LFS, and I'm trying to figure out the best approach.

  • What actually happened instead?

(See above)

  • If the problem was occurring with a specific repository, can you provide the
    URL to that repository to help us with testing?

Not at this time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions