On Sat, May 27, 2006 at 01:02:21AM +0400, Dmitry V. Levin wrote: > On Wed, May 10, 2006 at 05:28:24PM +0400, Dmitry V. Levin wrote: > > On Wed, May 10, 2006 at 05:07:52PM +0400, Alexey I. Froloff wrote: > > > * Dmitry V. Levin [060510 16:59]: > > > > > > > git-prune && git-repack -a -d -q > > > > > > > я пока что запускаю вручную. > > > > > > GIT_DIR=/path/to/project.git git-repack -a -d -q ? > > > > > Возможно, что GIT_DIR переопределять не надо. > > > > Да, достаточно одной строчки: > > > > git-prune && git-repack -a -d > > > Стоя в /path/to/project.git или в рабочей копии и потом это > > > push'нется ? > > > > Нет, в post-update, перед exec'ом. > > Сейчас у меня в post-update написано так: > git-prune && git-repack -a -d && git-update-server-info > > Должен заметить, что на репозитории packages/gcc3.4.git размером 42M > (в нём все 13 сборок пакета gcc3.4) эта операция (git-prune + git-repack) > потребляет заметное количество ресурсов. Сервер, выполняющий сейчас > обязанности devel.altlinux.org, ляжет очень быстро, если каждый мантейнер > будет выполнять эту операцию по своему разумению. Вообще-то обычно делают git-repack -a -d && git-prune-packed. git-prune - действительно очень ресурсоёмкая операция, но она нужна только в том случае, если в репозитории по каким-то причинам появились объекты, на которые нет ссылок. Кроме того, необходимо, чтобы при выполнении git-prune никто не писал в репозиторий (иначе только что добавленные объекты могут быть удалены, поскольку в этот момент на них ещё нет ссылок). На самом деле даже git-prune-packed может помешать выполняющимся параллельно операциям с репозиторием (если в момент начала операции git-repack ещё не успел создать новый pack-файл, а через некоторое время потребовались объекты, которые были помещены в новый pack и удалены git-prune-packed). Кроме того, если постоянно выполнять git-repack -a -d, нужно делать доступ через git daemon - нормально работать через http или rsync в таких условиях невозможно (при каждом git fetch всё будет скачиваться заново).