0

I have tracked some files in a Git repository with LFS and everything is in a clean state. When I delete an LFS-tracked file and then call git lfs pull, as my CI build script needs to do, the deleted file is immediately restored. Doing this before a commit would effectively prevent deleting LFS-tracked files.

How can I tell git-lfs to only pull those files that are actually referenced in the current working directory? If a pointer file is not there, that certainly has a reason.

ygoe
  • 18,655
  • 23
  • 113
  • 210
  • Probably related: https://stackoverflow.com/questions/34579211/how-to-delete-a-file-tracked-by-git-lfs-and-release-the-storage-quota – SparK Jun 23 '16 at 12:24

1 Answers1

1

It's not surprising this happens. git lfs pull explicitly requests that the state from the remote is merged into your current state – and hence, files that exist on the remote will be restored.

So, simply don't pull before you commit. That's the way git is supposed to work. Nothing broken here but your usage.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • I'm using a build&commit script that checks the build before committing. That workflow uses the same build script as the CI server. I'd really like to keep it that way... – ygoe Jun 23 '16 at 12:04
  • yeah well, but you can't pull before you commit. That simply doesn't make sense. – Marcus Müller Jun 23 '16 at 13:11
  • Why do the pointer files even exist if lfs-pull can download the files anyway? Is it supposed to have any meaning if those pointer files exist or not? – ygoe Jun 23 '16 at 15:20