145M = .git / об'єкти / pack /

Я написав сценарій, щоб додати розміри різниць кожного коміту та комітету, перш ніж він повернеться назад від кінця кожної гілки. Я отримую 129 Мб, що без стиснення і без обліку однакових файлів у гілках та загальної історії між гілками.

Git враховує всі ці речі, тому я би очікував набагато менший сховище. Так чому .git такий великий?

Я закінчив:

git fsck --full
git gc --prune=today --aggressive
git repack

Щоб відповісти про те, скільки файлів / комітетів, у мене є 19 гілок, приблизно 40 файлів у кожному. 287 комітів, знайдених за допомогою:

git log --oneline --all|wc -l

Для зберігання інформації про це не повинно зайняти 10 мегабайт.

Нещодавно я витягнув неправильне віддалене сховище у локальне ( git remote add ...і git remote update). Після видалення небажаного віддаленого списку, гілок і тегів у мене все ще було 1,4 ГБ (!) Марного місця в моєму сховищі. Я зміг позбутися цього лише клонуючи його git clone file:///path/to/repository. Зауважте, що file://створює світ різниці при клонуванні локального сховища - копіюються лише посилання, що посилаються, а не вся структура каталогів.

Редагувати: Ось один лайнер Яна для відтворення всіх гілок у новому репо:

d1=#original repo
d2=#new repo (must already exist)
cd $d1
for b in $(git branch | cut -c 3-)
do
    git checkout $b
    x=$(git rev-parse HEAD)
    cd $d2
    git checkout -b $b $x
    cd $d1
done

Деякі сценарії, які я використовую:

git-fatfiles

git rev-list --all --objects | \
    sed -n $(git rev-list --objects --all | \
    cut -f1 -d' ' | \
    git cat-file --batch-check | \
    grep blob | \
    sort -n -k 3 | \
    tail -n40 | \
    while read hash type size; do 
         echo -n "-e s/$hash/$size/p ";
    done) | \
    sort -n -k1

...
89076 images/screenshots/properties.png
103472 images/screenshots/signals.png
9434202 video/parasite-intro.avi

Якщо вам потрібно більше рядків, дивіться також версію Perl у сусідній відповіді: https://stackoverflow.com/a/45366030/266720

git-викорінення (для video/parasite.avi):

git filter-branch -f  --index-filter \
    'git rm --force --cached --ignore-unmatch video/parasite-intro.avi' \
     -- --all
rm -Rf .git/refs/original && \
    git reflog expire --expire=now --all && \
    git gc --aggressive && \
    git prune

Примітка: другий скрипт призначений для повного видалення інформації з Git (включаючи всю інформацію з відхилень). Використовуйте обережно.

git gcвже робить це, git repackтому немає сенсу в ручному перепакуванні, якщо ви не збираєтеся передати йому якісь спеціальні варіанти.

Перший крок - дізнатися, чи більша частина простору є (як це зазвичай було) вашою базою даних об’єктів.

git count-objects -v

Це повинно дати звіт про кількість розпакованих об'єктів у вашому сховищі, скільки місця вони займають, скільки пакуючих файлів та скільки місця вони займають.

В ідеалі після упаковки у вас не буде розпакованих об'єктів та одного файлу пакета, але цілком нормально, щоб деякі об'єкти, на які не посилаються безпосередньо поточні гілки, все ще були присутніми та розпакованими.

Якщо у вас є один великий пакет, і ви хочете знати, що займає місце, тоді ви можете перелічити об'єкти, які складають пакет, а також їх зберігання.

git verify-pack -v .git/objects/pack/pack-*.idx

Зауважте, що verify-packбере індексний файл, а не сам файл упаковки. Це дає звіт про кожен об'єкт в упаковці, його справжній розмір і розмір упаковки, а також інформацію про те, чи був він «дельфікований», і якщо так, походження дельтового ланцюга.

Щоб побачити, чи є у вашому сховищі якісь незвично великі об'єкти, ви можете сортувати вихідне число за третьою четвертою колонками (наприклад | sort -k3n).

З цього виводу ви зможете побачити вміст будь-якого об'єкта за допомогою git showкоманди, хоча неможливо точно побачити, де в історії фіксації сховища посилається об’єкт. Якщо вам потрібно це зробити, спробуйте щось із цього питання .

Тільки FYI, найбільшою причиною, чому ви можете виявити непотрібні об'єкти, є те, що git підтримує рефлог.

Рефлог є, щоб зберегти ваш приклад, коли ви випадково видалили свою головну гілку або якимось чином катастрофічно пошкодите ваше сховище.

Найпростіший спосіб виправити це - урізати ваші рефлоги перед стисканням (просто переконайтеся, що ви ніколи не хочете повертатися до будь-якого з комітетів у записі).

git gc --prune=now --aggressive
git repack

Це відрізняється від того, git gc --prune=todayщо у нього закінчується термін дії всього рефлогу відразу.

Якщо ви хочете знайти, які файли займають місце у вашому сховищі git, запустіть

git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5

Потім витягніть посилання на крапку, яка займає найбільше місця (останній рядок), і перевірте ім'я файлу, яке займає стільки місця

git rev-list --objects --all | grep <reference>

Це може бути навіть файл, який ви видалили git rm, але git запам'ятовує його, оскільки до нього ще є посилання, такі як теги, видалення та рефлог.

Коли ви дізнаєтесь, який файл ви хочете позбутися, рекомендую використовувати git forget-blob

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

Він простий у використанні, просто роби

git forget-blob file-to-forget

Це видалить кожну посилання з git, видалить крапку з кожного комітету в історії та запустить збір сміття, щоб звільнити місце.

Сценарій git-fatfiles з відповіді Ві прекрасний, якщо ви хочете побачити розмір усіх своїх крапок, але це так повільно, що бути непридатним. Я зняв обмеження на 40 рядків виходу, і він намагався використовувати всю оперативну пам’ять мого комп'ютера, а не закінчувати. Тому я переписав це: це в тисячі разів швидше, додав функції (необов’язково), і якийсь дивний помилка був видалений - стара версія дала би неточні підрахунки, якщо підсумувати вихід, щоб побачити загальний простір, який використовується файлом.

#!/usr/bin/perl
use warnings;
use strict;
use IPC::Open2;
use v5.14;

# Try to get the "format_bytes" function:
my $canFormat = eval {
    require Number::Bytes::Human;
    Number::Bytes::Human->import('format_bytes');
    1;
};
my $format_bytes;
if ($canFormat) {
    $format_bytes = \&format_bytes;
}
else {
    $format_bytes = sub { return shift; };
}

# parse arguments:
my ($directories, $sum);
{
    my $arg = $ARGV[0] // "";
    if ($arg eq "--sum" || $arg eq "-s") {
        $sum = 1;
    }
    elsif ($arg eq "--directories" || $arg eq "-d") {
        $directories = 1;
        $sum = 1;
    }
    elsif ($arg) {
        print "Usage: $0 [ --sum, -s | --directories, -d ]\n";
        exit 1;
    } 
}

# the format is [hash, file]
my %revList = map { (split(' ', $_))[0 => 1]; } qx(git rev-list --all --objects);
my $pid = open2(my $childOut, my $childIn, "git cat-file --batch-check");

# The format is (hash => size)
my %hashSizes = map {
    print $childIn $_ . "\n";
    my @blobData = split(' ', <$childOut>);
    if ($blobData[1] eq 'blob') {
        # [hash, size]
        $blobData[0] => $blobData[2];
    }
    else {
        ();
    }
} keys %revList;
close($childIn);
waitpid($pid, 0);

# Need to filter because some aren't files--there are useless directories in this list.
# Format is name => size.
my %fileSizes =
    map { exists($hashSizes{$_}) ? ($revList{$_} => $hashSizes{$_}) : () } keys %revList;


my @sortedSizes;
if ($sum) {
    my %fileSizeSums;
    if ($directories) {
        while (my ($name, $size) = each %fileSizes) {
            # strip off the trailing part of the filename:
            $fileSizeSums{$name =~ s|/[^/]*$||r} += $size;
        }
    }
    else {
        while (my ($name, $size) = each %fileSizes) {
            $fileSizeSums{$name} += $size;
        }
    }

    @sortedSizes = map { [$_, $fileSizeSums{$_}] }
        sort { $fileSizeSums{$a} <=> $fileSizeSums{$b} } keys %fileSizeSums;
}
else {
    # Print the space taken by each file/blob, sorted by size
    @sortedSizes = map { [$_, $fileSizes{$_}] }
        sort { $fileSizes{$a} <=> $fileSizes{$b} } keys %fileSizes;

}

for my $fileSize (@sortedSizes) {
    printf "%s\t%s\n", $format_bytes->($fileSize->[1]), $fileSize->[0];
}

Назвіть цей git-fatfiles.pl і запустіть його. Щоб побачити простір на диску, який використовується всіма версіями файлу, скористайтеся --sumопцією. Щоб побачити те саме, але для файлів у кожному каталозі, скористайтеся --directoriesопцією. Якщо ви встановите модуль Number: Bytes :: Human cpan (запустіть "cpan Number :: Bytes: Human"), розміри будуть відформатовані: "21M /path/to/file.mp4".

Ви впевнені, що рахуєте лише файли .pack, а не .idx файли? Вони знаходяться в тому самому каталозі, що і файли .pack, але не мають жодної з даних репозиторію (як вказує розширення, вони є не що інше, як індекси для відповідного пакету - адже, якщо ви знаєте правильну команду, ви можете легко відтворити їх з пакувального файлу, а сам git робить це під час клонування, оскільки лише пакетний файл передається за допомогою нативного протоколу git).

Як репрезентативний зразок, я розглянув мій локальний клон сховища linux-2.6:

$ du -c *.pack
505888  total

$ du -c *.idx
34300   total

Що вказує на збільшення приблизно 7%, має бути загальним.

Також є файли зовні objects/; в моєму особистому досвіді з них indexі, gitk.cacheяк правило, є найбільші (загалом 11 мільйонів у моєму клоні сховища linux-2.6).

Інші об’єкти git, що зберігаються, .gitвключають дерева, коміти та теги. Коміти та теги невеликі, але дерева можуть бути великими, особливо якщо у вашому сховищі є дуже велика кількість невеликих файлів. Скільки файлів і скільки комітетів у вас є?

Ви спробували використовувати git repack ?

перш ніж робити фільтр git-гілки та git gc, слід переглянути теги, які є у вашому репо-репо. Будь-яка реальна система, яка має автоматичне тегування для таких речей, як безперервна інтеграція та розгортання, зробить безперешкодні об’єкти такими тегами, отже, gc cant їх видалить, і ви все одно будете цікавитись, чому розмір репо все ще такий великий.

Найкращий спосіб позбутися від усіх непотрібних речей - запустити git-filter & git gc, а потім підштовхнути майстра до нового голого репо. Нове голе репо матиме очищене дерево.

Це може статися, якщо ви випадково додали великий фрагмент файлів і інсценізували їх, не обов'язково їх фіксуючи. Це може статися в railsдодатку, коли ви запускаєтесь, bundle install --deploymentа потім випадково git add .ви бачите всі додані під vendor/bundleвами файли, але їх уже не ввійшло в історію git, тому вам доведеться застосувати відповідь і змінити, video/parasite-intro.aviдо vendor/bundleцього запустіть другу команду, яку він надає.

Ви бачите різницю, з git count-objects -vякою в моєму випадку перед застосуванням скрипту був розмірний пакет: 52K, а після застосування - 3,8K.

Варто перевірити stacktrace.log. Це в основному журнал помилок для відстеження комітетів, які не вдалися. Нещодавно я дізнався, що мій stacktrace.log - 65,5 ГБ, а мій додаток - 66,7 ГБ.