Возможно ли получить информацию о том, сколько пространства потрачено впустую на изменения в каждой фиксации - так что я могу найти коммиты, которые добавили большие файлы или много файлов. Это все, чтобы попытаться уменьшить размер репозитория git (перезагрузка и, возможно, фильтрация)git find fat commit
ответ
Забыли ответить, мой ответ:
git rev-list --all --pretty=format:'%H%n%an%n%s' # get all commits
git diff-tree -r -c -M -C --no-commit-id #{sha} # get new blobs for each commit
git cat-file --batch-check << blob ids # get size of each blob
@sschuberth: Если я правильно прочитал ваш скрипт, он учитывает только файлы, которые были _added_ в конкретной фиксации. Он не обнаружит, когда файл существенно вырос в фиксации. – kynan
@kynan: Вы правы, поскольку это то, что запросил OP (и то, что мне было нужно). Но легко изменить сценарий для обнаружения измененных файлов: в основном вам просто нужно заменить «A» на «M» в вызове grep. Это сообщит об общем размере файла после модификации (а не о количестве добавленных/удаленных байтов). Я бы с радостью согласился с запросом на загрузку GitHub, чтобы сделать сценарий более общим. – sschuberth
Сломанная ссылка, скрипт теперь находится [здесь] (https://github.com/sschuber//dev-scripts/blob/master/git/git-commit-size.sh) – Luke
git cat-file -s <object>
где <object>
может ссылаться на фиксацию, blob, tree или tag.
Вы можете сделать это:
git ls-tree -r -t -l --full-name HEAD | sort -n -k 4
Это покажет самые большие файлы в нижней части (четвёртая колонка файл (клякса) размер
Если вы должны смотреть на разных веток». .. буду хотеть изменить ГОЛОВА на эти имена ветви или, это в цикле по ветвям, тегам, или набирает обороты вы заинтересованы в
Лично я нашел этот ответ, чтобы быть наиболее полезным при попытке найти большие файлы в истории в мерзавца репо: Find files in git repo over x megabytes, that don't exist in HEAD
#!/bin/bash
COMMITSHA=$1
CURRENTSIZE=$(git ls-tree -lrt $COMMITSHA | grep blob | sed -E "s/.{53} *([0-9]*).*/\1/g" | paste -sd+ - | bc)
PREVSIZE=$(git ls-tree -lrt $COMMITSHA^ | grep blob | sed -E "s/.{53} *([0-9]*).*/\1/g" | paste -sd+ - | bc)
echo "$CURRENTSIZE - $PREVSIZE" | bc
А также я предлагаю использовать git format-patch для получения размера фиксации (будет некоторый дополнительный размер для заголовка почты, но на самом деле, если вам нужно быстро совершить, это не слишком много - это не так важно чтобы получить точный размер, + - 1K будет хорошей точностью) –
git fat find N
где N в байтах будет возвращать все файлы в целом которые больше N байтов.
Вы можете узнать больше о мерзавец жира здесь: https://github.com/cyaninc/git-fat
Bummer. Я попробовал это на Git Shell для Windows, который поставляется с GitHub Desktop, и команда не работает, что дает мне ошибку. – DucRP
Все решения, приведенные здесь, сосредоточиться на размер файла но оригинальный вопрос спрашивает о фиксации размеров, которые, на мой взгляд, и в моем случае, было более важно найти (потому что я хотел бы избавиться от многих небольших двоичных файлов, введенных в одном коммите, которые суммировались с учетом большого размера, но небольшого размера, если измерять индивидуально по файлу).
Решение, которое фокусируется на фиксации размеров является при условии here, что этот сценарий Perl:
#!/usr/bin/perl
foreach my $rev (`git rev-list --all --pretty=oneline`) {
my $tot = 0;
($sha = $rev) =~ s/\s.*$//;
foreach my $blob (`git diff-tree -r -c -M -C --no-commit-id $sha`) {
$blob = (split /\s/, $blob)[3];
next if $blob == "0000000000000000000000000000000000000000"; # Deleted
my $size = `echo $blob | git cat-file --batch-check`;
$size = (split /\s/, $size)[2];
$tot += int($size);
}
my $revn = substr($rev, 0, 40);
# if ($tot > 1000000) {
print "$tot $revn " . `git show --pretty="format:" --name-only $revn | wc -l` ;
# }
}
И что я называю так:
./git-commit-sizes.pl | sort -n -k 1
Считайте просто запустив 'GIT gc' иногда , возможно, как 'git gc --aggressive' – Hasturkun
' git gc' (и 'git gc --prune'); '--aggresive' может даже дать худшие результаты (но обычно этого не делать), и обычно это не стоит. –
Этот ответ намного лучше: http://stackoverflow.com/a/10847242/520567 – akostadinov