Мені не вдалося скористатися найпопулярнішою відповіддю, оскільки --batch-checkперехід командного рядка на Git 1.8.3 (який я маю використовувати) не приймає жодних аргументів. Подальші кроки були випробувані на CentOS 6.5 з Bash 4.1.2
Основні поняття
У Git термін blob означає вміст файла. Зауважте, що фіксація може змінити вміст файла або ім'я шляху. Таким чином, один і той же файл може посилатися на іншу крапку залежно від фіксації. Певний файл може бути найбільшим в ієрархії каталогів в одному коміті, а не в іншому. Тому питання пошуку великих комітетів замість великих файлів ставить питання в правильну перспективу.
Для нетерплячих
Команда для друку списку краплин у порядку зменшення розміру:
git cat-file --batch-check < <(git rev-list --all --objects | \
awk '{print $1}') | grep blob | sort -n -r -k 3
Вибірка зразка:
3a51a45e12d4aedcad53d3a0d4cf42079c62958e blob 305971200
7c357f2c2a7b33f939f9b7125b155adbd7890be2 blob 289163620
Для видалення таких крапель використовуйте очищувач BFG Repo Cleaner , як зазначено в інших відповідях. Дано файл, blobs.txtякий містить просто хеші блобу, наприклад:
3a51a45e12d4aedcad53d3a0d4cf42079c62958e
7c357f2c2a7b33f939f9b7125b155adbd7890be2
Зробіть:
java -jar bfg.jar -bi blobs.txt <repo_dir>
Питання в тому, щоб знайти коміти, це більше роботи, ніж пошук крапів. Щоб знати, читайте далі.
Подальша робота
З огляду на хеш комітів, команда, яка друкує хеші всіх об'єктів, пов'язаних з ним, включаючи краплі, є:
git ls-tree -r --full-tree <commit_hash>
Отже, якщо у нас є такі виходи для всіх комітетів у репо, тоді, якщо дано хеш-блош, група комітетів є тими, які відповідають будь-якому з результатів. Ця ідея закодована у наступному сценарії:
#!/bin/bash
DB_DIR='trees-db'
find_commit() {
cd ${DB_DIR}
for f in *; do
if grep -q $1 ${f}; then
echo ${f}
fi
done
cd - > /dev/null
}
create_db() {
local tfile='/tmp/commits.txt'
mkdir -p ${DB_DIR} && cd ${DB_DIR}
git rev-list --all > ${tfile}
while read commit_hash; do
if [[ ! -e ${commit_hash} ]]; then
git ls-tree -r --full-tree ${commit_hash} > ${commit_hash}
fi
done < ${tfile}
cd - > /dev/null
rm -f ${tfile}
}
create_db
while read id; do
find_commit ${id};
done
Якщо вміст буде збережено у файлі з назвою, find-commits.shтиповий виклик буде таким:
cat blobs.txt | find-commits.sh
Як і раніше, у blobs.txtсписку файлів є хеші блоків, по одному на рядок. create_db()Функція зберігає кеш всіх фіксації списків в підкаталог в поточному каталозі.
Деякі статистичні дані з моїх експериментів над системою з двома процесорами Intel (R) Xeon (R) процесора 2,00 ГГц, що представлені ОС як 24 віртуальних ядра:
- Загальна кількість комісій у РЕПО = майже 11 000
- Швидкість створення файлу = 126 файлів / с. Сценарій створює один файл на комісію. Це відбувається лише тоді, коли кеш створюється вперше.
- Створення кешу накладних витрат = 87 с.
- Середня швидкість пошуку = 522 коміти / с. Оптимізація кешу призвела до скорочення часу на 80%.
Зауважте, що сценарій є однопоточним. Тому за один раз буде використано лише одне ядро.
