Re: Migration to Git LFS inflates repository multiple times

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.