On Mon, Nov 12 2018, Jeff King wrote: > On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote: > >> Hi, >> >> I'm posting here for the first time and I hope it's the right place to ask >> questions about Git LFS. >> >> TL;TR: Is this normal a repository migrated to Git LFS inflates multiple times >> and how to deal with it? > > That does sound odd to me. People with more LFS experience can probably > give you a better answers, but one thought occurred to me: does LFS > store backup copies of the original refs that it rewrites (similar to > the way filter-branch stores refs/original)? > > If so, then the resulting repo has the new history _and_ the old > history. Which might mean storing those large blobs both as Git objects > (for the old history) and in an LFS cache directory (for the new > history). > > And the right next step is probably to delete those backup refs, and > then "git gc --prune=now". Hmm, actually thinking about it, reflogs > could be making the old history reachable, too. > > Try looking at the output of "git for-each-ref" and seeing if there are > any backup refs. After deleting them (or confirming that there aren't), > prune the reflogs with: > > git reflog expire --expire-unreachable=now --all > > and then "git gc --prune=now". Even if it's only the most recent version of each file this could also be explained by LFS storing each file inflated as-is on disk, whereas git will store them delta-compressed. According to the initial E-Mail "*.exe,*.dll,*.lib,*.pdb,*.zip" was added to LFS. Depending on the content of those they might be delta compressing somewhat better than random data.
