12

I have only found git lfs ls-files but this command give only the list from a specific ref.

There is a way to have the whole list of LFS object from a GIT repository?

FearlessHyena
  • 2,266
  • 27
  • 34
  • What did you mean with "from a specific ref"? When I execute "git lfs ls-files" it lists all LFS files of the repository. – Marcelo Ávila de Oliveira Sep 11 '17 at 14:14
  • In fact, git lfs ls-files give only the list of LFS object of the current branch/tag or a specific given reference as argument. In my case I want to have the complete list including all branch/tags an history... – Emeric Verschuur Sep 12 '17 at 12:44
  • Ok, now I understood your question. I answered below... if you have any issues let me know. – Marcelo Ávila de Oliveira Sep 12 '17 at 13:01
  • Does that mean that you would want LFS objects that have been deleted in the past included as well? What about objects that have changed? Should they appear multiple times? (as they would be different LFS objects, with different LFS Object IDs) – Svend Hansen Sep 12 '17 at 13:59
  • Yes, is exactly that i want. I need the whole list including updated objects (one hash by update), deleted, etc. In fact all objects referenced in the project life. The aim of this list is to build the complete object list of all my git projects and next remove all orphan ojects of my LFS server (It's a kind of garbage collector) – Emeric Verschuur Sep 12 '17 at 14:28

4 Answers4

18

You can do this in Git LFS v2.4.0 and later using the --all flag

git lfs ls-files --all

You can read more about it in this pull request

FearlessHyena
  • 2,266
  • 27
  • 34
1

If you have access to the git LFS server, you can look in the lfs/objects folder. Is should contain a folder structure that works like a search tree for the stored objects. At some level (maybe third?) are the objects themselves.

A small example with a tiny project I just converted to git (and git lfs) to test this looks like this:

$ ls lfs/objects/*/*
lfs/objects/9f/ef:
9fef0fcd855a78effd175cdf5a49a14b57334b40f1ad0c75317d6cbc0bb29595

lfs/objects/a5/f2:
a5f207bf721d3cbf62d298b6e2c9fa7cbdb3e37c7f44590a6c8be76560d7b9d7

lfs/objects/ca/63:
ca631009296d9de54dde2f70fec997aa0b22f624ed8f6fecc763c684317ba825

In my case this is inside the .git folder. I haven't pushed it to a git LFS server, but I presume the structure is the same on there. This should (as far as I can tell) give you all the hashes (as the file names) of all the files stored in git LFS.

Note: I'm basing this on experimenting with git LFS and noting what happens. Not from any deeper understanding on how the storage system behind git LFS works.

Svend Hansen
  • 3,045
  • 3
  • 28
  • 45
  • 1
    Yep, the hash on the server is split like this: [0-9a-f]{2}/[0-9a-f]{2}/[0-9a-f]{60} and the concatenation of the tree parts give the sha256 given by the git lfs ls-files -l – Emeric Verschuur Sep 13 '17 at 08:09
  • Looks like the file names alone (without concatenating with path) is the entire sha256. For instance the `9f` and `ef` in the path of the first file, is also in the file name (and the file name is the full 64 char hash listed by `git lfs ls-files -l` in my case) :) – Svend Hansen Sep 13 '17 at 11:21
  • 1
    indeed... on the embedded gitlab one I have: `gitlab-rails/shared/lfs-objects/00/05/90ed62b7424f71912fae5e0f7e1216105937b9efa1b33e6d7ce6503a23a9 gitlab-rails/shared/lfs-objects/00/5a/01c86eda80a7aa523c72c5a10eb4c5ee1ffad958de1fddf408efd21fe2f9 gitlab-rails/shared/lfs-objects/00/a2/847068165713cc2c3266b7d996c14fc8982d6222df438e3ebfba9fe0096a` – Emeric Verschuur Sep 13 '17 at 11:33
  • Right, now I see what you're saying. I'm a bit slow. That's what it's like on the server. Mine isn't on the server. Makes sense :) Sounds like you might get a better solution from the git-lfs guys :) – Svend Hansen Sep 13 '17 at 11:39
0

The "git lfs ls-files" command can't list all LFS objects for the repository the way you want. The command need to list the LFS objects for a specific reference. It's easy to understand why it can't do that if you remember that each reference represent a snapshot of the repository history. The same behaviour happens with the "git ls-files" command, you can't list all files for all repository revisions (commits) at the same time.

0

I have added an issue on the GIT LFS Github: https://github.com/git-lfs/git-lfs/issues/2575