Re: Migration to Git LFS inflates repository multiple times
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 12, 2018, 12:42 UTC
- Message-ID
- <87k1li31si.fsf@evledraar.gmail.com>
- In-Reply-To
- <20181112123058.GE3956@sigill.intra.peff.net>
On Mon, Nov 12 2018, Jeff King wrote:
Show 31 quoted lines
> 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.