Джошуа Редстоун (Joshua Redstone)
пожаловался в листе рассылки Git на некоторые проблемы с производительностью, которые возникли у Facebook на большом репозитории. Они создали синтетический репозиторий и провели тесты.
Тестовый репозиторий
4 млн коммитов, линейная история и около 1,3 млн файлов. Размер папки .git — около 15 ГБ, её упаковали командой repack:
git repack -a -d -f --max-pack-size=10g --depth=100 --window=250
Процесс занял около двух суток на хорошей машине (много памяти, SSD). Размер индексного файла составил 191 МБ.
При чтении обучающих статей про систему контроля версий git я заметил одно свойство, большинство из них направлено на то, чтобы читатель уяснил все плюсы распределенной системы контроля версий. В этом разрезе обычно рассказывают об удаленных репозиториях, ветках, пушах, пулах и т. д.
Но в использовании какого-то инструмента возникает такой момент (особенно, если изучение его идет по разным факам, форумам, статьям в интернете), когда вроде бы знания по работе с ним уже получены достаточно, но все равно чувствуешь, что в каких-то моментах ты немного плаваешь. Значит настало время взять в руки нормальную книгу и начать ее читать от корки до корки.
Конечно, может быть такой подход следует применять с самого начала… даже не может быть, а нужно применять с самого начала, но на нормальное изучение как обычно не всегда хватает времени, сил, желания и т. д.
Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect
1 февраля 2012, 14:13
273
Данная мини-заметка в первую очередь является ответом на
вопрос.
Так как мой аккаунт read-only, то вот такой вот способ ответа. «А жизнь-то налаживается!» ©
Первый вывод после прочтения вопроса и ответов — не делайте так, как предложил
defuz. Он не понимает суть проблемы, и если вы сделаете как им предложено — скорее всего, вы потеряете данные.
Второй:
alekciy тоже не совсем прав, но тут шансов на потерю данных гораздо меньше. Почти никаких.
Ну и третий: блин, ну когда же люди поймут, что владеть используемым инструментом это реально необходимо? Читайте документацию!
23 января 2012, 20:05
138
gitolite — это средство для создания централизованных репозиториев для совместной разработки через git.
Зачем оно нужно?
Родные средства git для этой задачи на сегодня явно недостаточны: родной git-протокол не содержит каких-либо средств авторизации, а для работы через ssh потребуется завести полноценного юзера в ОС (с шеллом), что далеко не всегда уместно и желательно.
gitolite же позволит вам заводить пользователей независимо от наличия аккаунта в ОС и гибко раздавать права.
23 января 2012, 15:10
158

22 декабря мы зарелизили версию 2.0.
Основные изменения:
- Переезд с gitosis на gitolite.
- Пересмотрен дизайн. Теперь он более удобен и практичен.
- Улучшенное управление правами
- Улучшенная система email — нотификации.
- Улучшение dashboard.
- Улучшение работы дерева файлов и каталогов.
- Atom лента для комитов и тасков.
- Багофикс + другие мелкие изменения.
25 декабря 2011, 21:52
152
Около полутора лет назад мы анонсировали
поддержку svn, которая позволила ограниченно использовать репозитории GitHub через клиенты subversion.
Сегодня мы запускаем новую улучшенную поддержку svn.
Что нового?
Хотите поднять клон Github на своём собственном сервере с приватными репозиториями за корпоративным файрволом? Теперь вы можете это сделать благодаря появлению open source проекта
GitLab. Он является хорошей альтернативой для
корпоративной версии Github стоимостью до $5000 в год.
По сравнению с
Gitorious, система GitLab отличается приятным интерфейсом и
гораздо проще в установке.
13 октября вышла версия 1.0, через неделю обещают выкатить 1.1, а затем новые релизы GitLab 1.2, 1.3 и т.д.
будут выходить каждый месяц.
17 октября 2011, 13:34
153
Здравствуйте,
Тихо и незаметно (по крайней мере на Хабре) вышло обновления для git.
Полный changelog. Кратко опишу главные вкусности, которым я очень рад и думаю вы тоже будете рады.
16 октября 2011, 18:55
11
Привет, товарищ!
Как все знают, довольно большое распространение получает система контроля версий git.
И все бы хорошо, но многими любимый Gitosis не дружит с АД, а работа через http
немного туповата.
Особенно, если настроен через WebDAV.
И тут я немного расскажу как подружить git с AD с последующим использованием через ssh.
К моему удивлению, в рунете (да и на просторах интернационального интернета) я подобных инструкций не видел.
Что у нас есть:
* Debian lenny
* git 1.7
Что нужно:
* openlikewise
* acl
И так. Быстрый HOWTO.