0

I'm using Git 2.38.0.windows.1 on Windows with git-lfs/3.2.0 (GitHub; windows amd64; go 1.18.2). I haven't used Git LFS in a while. I have a repository hosted in GitHub with some large PNGs. I wanted to start storing the PNGs in LFS. I already had .gitconfig set up from a previous machine, but I ran git lfs install just in case.

Then I did:

git lfs migrate import --everything --include="*.png"
git push --force

Now the content of all my images/*.png in the working tree have been replaced with the placeholder text files, with the hash and size. I had thought (remembering the last time I worked with Git LFS) that the working tree held the actual files, but that the placeholder files were used in history.

After reading an excellent summary on Stack Overflow, I performed the following command:

git lfs checkout

The actual files reappeared in my repository. This tells me (based upon the summary I referenced above) that the files must have already been in my .git/lfs directory after migration. So in the future my LFS migration workflow will end in git lfs checkout.

But is this correct, expected behavior? Does migration end with only placeholder files in the working tree? Why? The Git LFS Tutorial doesn't say anything about git lfs checkout after migration.

Won't a git clone of a new repository result in the actual files in the working tree, or would I need a git lfs checkout after git clone as well?

Garret Wilson
  • 18,219
  • 30
  • 144
  • 272
  • Git itself has nothing to do with this: all the choices are up to the LFS wrappers. Doing a plain `git clone` will or won't work depending on whether the LFS wrappers are already installed and configured as necessary. The core Git code is not aware that LFS is doing things behind its back, and only ever sees the pointer files. (I don't use Git-LFS, after a very brief experiment with it, so I'm not sure what its defaults are these days.) – torek Oct 20 '22 at 00:19

0 Answers0