The Lost and The Found

Что означает "Реальное время".

Wed, 16 Sep 2009 15:54:17 GMT

В последнее время приходится достаточно часто разговаривать и переписываться с людьми, которые часто употребляют термин "реальное время" и "ОС реального времени". И, судя по контексту обсуждения, многие плохо себе представляют, что же это такое, как в таких ОС осуществляется планирование, как расставлять приоритеты задач в таких системах и т.д.

Если и вы из таких людей, то возможно вам будет интересно то, что под катом... Но предупреждаю - букв Реально много.

Например, часто встречается мнение, что более важные для работы процессы должны получать больший приоритет, а менее важные - меньший. То есть решение о планировании таких процессов принимается исходя из каких-то априорных соображений типа "ввод-вывод должен быть побыстрее, технологическая задача должна иметь средний приоритет, а уж связь с системами верхнего уровня должна быть самой низкоприоритетной".

Звучит в общем-то разумно, не правда ли?

Также бытует мнение, что ОСРВ работает "быстрее" и "надежнее", и что если взять обычную систему, и перенести ее в РВ-окружение, то все магическим образом будет работать правильно.

На вопрос "а с чего должно быть быстрее", обычно отвечают - "ну как же, это ж РЕАЛ-ТАЙМ! Он ГАРАНТИРУЕТ, что все выполнится в выставленные сроки!".

Как правило, в качестве определения системы реального времени приводится некий "отказ", если какая-то операция не укладывается в гарантированные рамки. По этому отказу могут проводиться какие-то контраварийные действия, например остановка производства, срабатывание систем противоаварийной защиты, все рабочие на производстве срочно натягивают строительные каски на головы и быстро покидают объект... Это жесткое (hard) Реальное Время. Звучит страшно, и внушает уважение к этому "реальному жосткому времени для реальных жостких пацанов".

В действительности же, в большинстве ситуаций, необходимости в такой обработке ситуации "превышение временных рамок или дедлайна" нет... Как правило, программист обрабатывает такую ситуацию, просто повторяя неудавшийся запрос. Такое "ленивое" реальное время еще называют "мягким (soft)".

Так что же такое - это самое Реальное Время? Чтобы понять это, представим систему, которая закручивает крышечки бутылок Nuka-Cola на заводе. Допустим, это большой конвейер, на который выставляются пустые бутылки, они подходят к аппарату, заполняющему их свежей ну-ка-колой, выходят с другой стороны и поступают к роботу, закручивающему крышечки.

Для простоты представим, что конвейер движется со скоростью одна бутылка в секунду. То есть за одну секунду лента конвейера успевает подать новую бутылку, дождаться пока автоматы по всей линии конвейера сделают свои дела (заполнят бутылку, накрутит крышку, наклеят этикетку etc), и сдвинуть ленту дальше, чтобы подать следующую бутылку. Таким образом, на таком конвейере все передвижения ленты происходят с периодичностью в секунду. Эта величина называется периодом выполнения задачи (task period), обозначим ее как Т = 1000 мс.

Далее, допустим что на запуск, протяжку и остановку ленты, тоже тратится некоторое время (из этой одной секунды), и работа всех механизмов во время протяжки ленты невозможна. Например, на протяжку тратится 200 мс из каждой секунды, так что с момента остановки ленты до момента начала её движения остается 800 мс, и работа всех агрегатов конвейера должна быть завершена за это время. Это время называется дедлайном (deadline) задачи, обозначим его как D = 800 мс.

Теперь рассмотрим только робота, закручивающего крышки. Допустим, что робот устанавливает и закручивает крышку за 200 мс. Эта величина называется временем исполнения (computation time), обозначим ее как C.

Что же получилось в итоге? Каждую секунду к роботу подъезжает новая бутылка, он за 200 мс закручивает ее крышку, и остается еще 600 мс до того, как лента начнет двигаться, и 800 мс до подъезда следующей бутылки. Итого, робот работает только 20% (200 мс / 1000 мс * 100%), а остальное время ничего не делает. Величина, равная отношению времени исполнения к периоду исполнения, называется загруженностью (utilization) и обозначается как U. В такой системе робот всегда выполняет все свои задачи в срок, и это - система жесткого реального времени.

Но для такого дорогого оборудования, 20% загрузка это слишком мало. И тут инженеру, изнывающему без премий, приходит в голову гениальная мысль! А что если поставить рядом две конвейерные ленты, а робота снабдить поворачивающимся основанием? Тогда он сможет закручивать крышки на двух лентах, периодически переключаясь между ними. Все довольны, руководство завода пропивает стоимость второго робота вмести с изобретательным инженером.

Но возможно ли это сделать так, чтобы не приходилось останавливать конвейеры? То есть, можно ли сделать так, чтобы все задачи выполнялись до достижения дедлайна? Этот вопрос придётся решать бедняге инженеру, когда он проспится после грандиозной попойки и придёт программировать робота.

Допустим, второй конвейер разливает не ну-ка-колу, а нано-колу. Она менее вязкая, в результате чего удалось поднять скорость второго конвейера до одной бутылки за 600мс. T' = 600 мс.
При этом лента его движется с той же скоростью, что и у первого. затрачивая те же 200 мс на протяжку. То есть время дедлайна равно D' = 400 мс. Время закручивания крышки оставляем тем же - 200 мс (C' = C = 200 мс).

Также, требуется определенное время для переключения робота с одной ленты на другую. Допустим, что робот у нас поворачивается за 200 мс. Это время называется временем переключения контекста.

Задача распределения робота между этими двумя лентами, так чтобы дедлайны не превышались - это и есть типичная задача планирования в системах реального времени.

Начинается ее решение с того, что проверяется суммарная загрузка системы, не превышает ли она 100%. Если превышает - то задача в принципе не решаемая, какой-то из конвейеров придется тормозить. Эта величина складывается как сумма загруженностей отдельных лент.

В нашем случае она равна U + U' = C/T + C'/T' = 200/1000 + 200/800 = 0.45, то есть 45%. Это не так уж много. Теперь посмотрим, удастся ли найти такой алгоритм планирования, который бы не превышал дедлайны, с учетом времени переключений контекста. Для иллюстрации процесса очень полезно иметь при себе диаграмму процесса, подобную приведенной на рисунке 1.

Верхняя линия - это более медленный конвейер, нижняя - более быстрый. Стрелочками показаны переключения робота между линиями, звездочками - закручивание крышек. Закрашенными прямоугольниками показываются дедлайны, промежутки между ними - это протягивание линии. Серый прямоугольник - простой робота.

Рисунок 1.

Это диаграмма показывает планирование на протяжении 4 секунд. После окончания четырех секунд, робот находится в том же положении, что и был изначально, так что такое планирование можно "зациклить". Как видно, задача планирования решена - все крышки закручены вовремя. Но какой ценой? Робот простаивал только 400 мс из всех четырех секунд, то есть реальная загрузка с учетом переключений составила 90%! В два раза больше расчетных 45% (без учета переключений контекста).

В общем и целом, каждую конкретную систему так, вручную распланировать конечно не получится. В обычной промышленной системе таких задач могут быть десятки, и к одновременному старту могут быть готовы сразу несколько. Поэтому на помощь приходят алгоритмы планирования.

Делятся они, в основном, на два типа - динамические и статические. Динамические планировщики оперируют в предположении, что каждая задача сообщает планировщику, какой у нее период, и каков дедлайн, а также время исполнения, так что планировщик в любой момент знает, когда нужно переключать процессы.
В качестве примера динамического планирования можно привести алгоритм Ealiest Deadline First (EDF). Когда имеются две задачи, между которыми нужно выбирать, выбирай ту, у которой раньше всего истечет дедлайн. Такой планировщик требует наиболее точных знаний о системе, но зато, позволяет нагрузить все 100% ресурсов (система остается планируемой даже если суммарная загрузка равна 100%).

Статические планировщики производят планирование по приоритетам. Каждой задаче назначается свой приоритет (в соответствии с алгоритмом планирования), и далее, планировщик всегда выбирает процесс с наибольшим приоритетом. Одним из примеров таких алгоритмов является Rate-monotonic Scheduling (RMS). В нем приоритеты назначаются согласно длительности цикла задачи - чем меньше T, тем больше приоритет. Для такой системы, чтобы оставаться планируемой, необходима загрузка меньше чем определенное число, обычно большее чем 69%.

Вышеприведенные рассчеты с роботом подразумевают, что задачи могут работать совершенно независимо друг от друга, не имея никаких общих ресурсов кроме времени робота. Чаще всего это не так. Между процессами обычно происходят взаимодействия, синхронизации, так что один может заблокировать выполнение другого (например, семафором).

Впрочем, об инверсии приоритетов, пожалуй, в следующий раз, если кому-нибудь это вообще интересно.

Посоветуйте новый телефон

Tue, 28 Apr 2009 07:31:03 GMT

В очередной раз сломалась гарнитура для K750i (стоимостью в 800 р), что повергло меня в уныние, потому что количество кровно заработанных рубликов, потраченных на проводные гарнитуры, уже вплотную подбирается к стоимости телефона, который у меня кстати уже три года.

В связи с этим возникла необходимость сменить телефон на что-то более современное, с поддержкой высокоскоростного GPRS/EDGE, а то обычный тормозной GPRS в K750i уже достал.

Также необходимы следующие штуки:
1) Стандартный разъем для подключения к компу/подзарядки (предпочтительно mini-USB)
2) Стандартный разъем для подключения наушников (предпочтительно mini-jack).
3) Поддержка внешних карт памяти (предпочтительно SD)
4) FM-радио, и MP3-плеер внутри
5) Фотокамера с автофокусом, автоматическим балансом белого, разрешение не менее 2 мегапикселей.
6) Bluetooth обязателен, Wi-Fi опционален.
7) Поддержка в Linux в качестве GPRS модема.
8) Громкий будильник

Ну и чтоб не сдыхал после дня использования в качестве радио или плеера.

Может кто-то может что-нибудь посоветовать? Иначе придется разоряться на новую гарнитуру и терпеть тормознейший GPRS.

National

Thu, 27 Nov 2008 08:43:02 GMT

Когда читаю российскую прессу (в частности, Компьютерру), глаз всегда спотыкается на расшифровках различных американских названий типа NASA, NBA, NPR, National Geographic и т.п. Везде "National" переводится как "Национальный/ая/ое".

Ну, для американцев, создающих эти названия для внутреннего пользования, слово "National" в общем-то понятно. У них там штаты - как отдельные государства, поэтому для обозначения "общештатовских" понятий используются прилагательные Федеральный и Национальный.

Но для нас, иностранцев, считаю, правильнее переводить National как Американский. Мы ж не в дефолт-стране живем.

Итого получается -
NHL - Американская Хоккейная Лига
NBA - Американская Ассоциация Баскетбола
NPR - Американское Общественное Радио
NASA - Американское Аэрокосмическое Агенство
National Geographic - Американское Географическое Сообщество

И т.п.

Кстати, в отличие от Дефолт-страны, в Великобритании любят слово British. ;)

C++ FQA

Tue, 25 Nov 2008 16:04:59 GMT

[21.6] Is a Circle a kind-of an Ellipse?
FAQ: Sometimes it is, most frequently it isn't.

Q: But I have a Ph.D. in Mathematics, and I'm sure a Circle is a kind of an Ellipse! Does this mean Marshall Cline is stupid? Or that C++ is stupid? Or that OO is stupid?

FAQ: It means a different thing: your intuition is wrong in the sense that it leads you to make wrong decisions about inheritance. The right way to think about "kind-of" is this: B is a kind of A if you can always substitute a B for an A.

FQA: Instead of admitting that OO is not a natural language, and it doesn't have to map directly to a natural language, the FAQ actively tries to persuade you to change the way you use natural language words to make your thinking OO-compatible. Next, they'll ship patches you should apply to your DNA, and a sticker saying "Designed for C++ Programming" for your skull.

http://yosefk.com/c++fqa/inheritance-proper.html

Читаю уже неделю потихоньку, ржу в голос.

Еще один тест (стырено у icesik)

Sat, 15 Nov 2008 14:47:27 GMT

есть люди - Скалы

С ними всегда можно быть уверенным, что ничего не случится и что всегда находишься под защитой. есть на кого опереться и положиться в трудной ситуации. Они тверды и решительны, и никогда не отступают от своих решений

Пройти тест

Похоже.

git 1.6.0

Tue, 21 Oct 2008 17:42:34 GMT

В Сизиф приехал новый git. В нем принято решение убрать из PATH команды типа git-foo, оставив там только git. Итого для работы приходится использовать git foo вместо git-foo.

Из этой ситуации есть два выхода. Первый - пройтись по всем своим самописным скриптам с sed -i "s/git-/git /g". После чего приучать свои пальцы вместо минуса пробел рисовать.

Второй способ легче - добавляете в PATH /usr/libexec/git-core.
И живете как раньше.

Успехи прикладной лоботомии

Tue, 14 Oct 2008 12:43:23 GMT

http://www.adme.ru/sberbank/2008/09/11/23801/

Новые маскоты сбербанка - лоботомированные вкладчики без мозга, Сберик и Сберочка:

Дизайнерам - EPIC FLAIL.

Это ожившие эмблемы Сбербанка, которые в свою очередь означают кошелек.

Преимущество Linux для образования

Tue, 30 Sep 2008 07:44:20 GMT

http://sevik.ru/syslinux/
.....
Несмотря на разнообразие посвященной ядру Linux литературы, единственным заведо-
мо актуальным источником информации о ядре являются исходные тексты используемой
версии ядра. Одной из причин этому является постоянное изменение внутренних струк-
тур данных ядра и заголовков функций даже при смене номера минорной версий ядра. В
силу этого исходный код, работоспособный в версии 2.6.9, в версии 2.6.25 обычно не про-
ходит даже этап компиляции. Данная проблема значительно усложняет разработку сто-
ронних драйверов. С другой стороны, она же приводит к определенным сложностям
при сдаче прошлогодних курсовых проектов, что выглядит скорее как достоинство
при использовании ядра Linux в учебных целях (замечание Крищенко В. А.).
.....

День программиста

Fri, 12 Sep 2008 06:33:18 GMT

Поздравляю всех программистов с нашим профессиональным праздником! Ура! Ура! Ура!

Выдержка из лога

Thu, 21 Aug 2008 12:43:13 GMT

Выдержка из лога

xxx: Коли то, о чем ты просишь, не трудно, я готов.
yyy: Что же, тебе кажется трудным отвечать на вопросы?
xxx: Нет, не кажется.
yyy: Так отвечай же.
xxx: А ты спрашивай.
yyy: Значит, я буду задавать тебе вопросы так, как если бы ты в самом деле замышлял то, о чем я сейчас говорил?
xxx: Да, если тебе так угодно; хотел бы я знать, каковы будут твои вопросы.

Кажется разговором двух интеллектуалов в аське, не так ли?

Однако этому логу 2300 лет. Платон, Диалоги, Алкивиад I.

Контраст с башоргом налицо :)

Eclipse, Moscow

Fri, 01 Aug 2008 16:53:25 GMT

Mon, 30 Jun 2008 11:59:20 GMT

26 :)

Edit:
Большое спасибо всем поздравляющим - я очень ценю вашу поддержку!

Edit2:
Ну чтож, пожалуй это был лучший мой день рождения за последние 10 лет :) Столько неожиданных сюрпризов :) Праздник действительно получился :)

Тесты, которые проходят нас :)

Thu, 12 Jun 2008 12:55:57 GMT

Я проверил свои знания русского языка и получил пятерку.

Сходи, проверься?

Git Guts (part 7)

Sun, 06 Apr 2008 15:43:21 GMT

Ветки в git - как ветки деревьев, постоянно обновляются и растут. Одно и то же символьное имя ветки (refs/heads/foo) может указывать на разные коммиты в разные моменты времени. В отличие от веток, теги (tags) - специально созданы для неизменяющихся по времени ссылок.

Символьные имена для тегов лежат в .git/refs/tags. Каждому имени тега может соответствовать один объект в базе git. Это может быть любой из ранее перечисленных типов объектов - блобы, деревья, коммиты.
Символьное имя, указывающее на блоб, дерево или коммит, в терминологии git называется легковесным (lightweight) тегом. Легковесный он потому что кроме SHA1-имени, никакой другой информации не записывается.

Такие легковесные теги можно создавать путем записи SHA1-имени объекта в файл в директории .git/refs/tags/<имя тега>.

Настоящие теги - тяжеловесные или аннотированные (annotated), состоят из двух частей. Первая часть - это объект базы git специального типа (tag). В этот объект записываются следующие данные:

SHA1 объекта, на который указывает аннотированный тег.

Тип этого объекта (blob, tree, commit или tag) (да, бывают теги указывающие на теги!)

Символьное имя тега

Дата и время создания тега

Имя и e-mail создателя тега (в таком же формате как имя автора коммита)

Кусок произвольных данных на усмотрение создателя тега

После чего объект-тег записывается в базу git, и в .git/refs/tags/<имя тега> пишется SHA1 объекта-тега.

В тот самый кусок произвольных данных могут быть записано сообщение тега (по смыслу аналогичное сообщению коммита), а также в него можно внедрить GPG-подпись объекта. Такой тег будет называться подписанным (tag).

Вот тут и проявляется магия git - создавая подписанный тег на определенный коммит, на самом деле подписывается и сам коммит, и вся его история, и все деревья, составляющие историю, и все блобы, "висящие на ветках этих деревьев". То есть все, на что можно "дотянуться" по ссылкам от коммита.

Ладно, хватит теории, давайте перейдем к практике.

Обычные, легковесные теги, как я уже говорил раньше, можно создавать просто записывая SHA1-имя объекта в файл в директории refs/tags/.

Однако правильней создавать их через утилиту git-tag <имя тега> [<имя объекта>]

Если имя объекта не указывать, то по умолчанию тег будет указывать на тот же коммит, на который указывает ссылка HEAD.

Сначала создадим объект на который будет указывать тег. Для иллюстрации я создаю простейший blob, хотя обычно теги указывают на объекты-коммиты.

$ mkdir ~/tmp/gitguts7
$ cd ~/tmp/gitguts7
$ git-init
$ export GIT_AUTHOR_NAME="Git Guts"
$ export GIT_AUTHOR_EMAIL="gitguts@localhost"
$ export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
$ export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
$ echo "Testing blobs" > blobtest
$ git-hash-object -w blobtest
717c935c292fee3dca4c2e5f335f27b657895368

Теперь создаем легковесный тег

$ git-tag lighttag 717c935c292fee3dca4c2e5f335f27b657895368
$ cat .git/refs/tags/lighttag
717c935c292fee3dca4c2e5f335f27b657895368

Как видно, по содержанию легковесные теги ничем не отличаются от бранчей - это обычные файлы с SHA1 объекта внутри.
Кстати, команда git-tag без параметров (или git-tag -l) выведет список тегов.

Теперь создадим аннотированный тег (с помощью git-tag -a). Для создания аннотированного тега необходимо указывать практически то же, что и для создания коммита - то есть имя автора тега, дату создания и сообщение. Ну и чтобы получилось одно и то же время, я опять воспользуюсь программой faketime. В отличие от git-commit-tree, команда git-tag более высокоуровневая, и сообщение для тега можно задавать прямо в командной строке, используя параметр -m.

$ faketime -t 200001010000 git-tag -m 'Test annotated tag' -a annotated_tag lighttag

Заметьте, вместо использования SHA1 blob-а, я использовал ранее заданное имя lighttag, которое указывало на этот blob. В этом и весь смысл тегов - давать символьные имена объектам из базы.

Теперь давайте посмотрим, что же получилось в итоге

$ git-rev-parse annotated_tag
40f93cdf3db19ab20109c81f113a7ccb8b921827
$ git-cat-file tag annotated_tag
object 717c935c292fee3dca4c2e5f335f27b657895368
type blob
tag annotated_tag
tagger Git Guts <gitguts@localhost> 946674000 +0300

Test annotated tag

Первая команда (git-rev-parse), позволяет посмотреть, каков SHA1 самого объекта-тега. Вторая команда распечатывает содержимое объекта-тега. В нем можно увидеть SHA1 блоба (первая строчка), тип объекта (вторая строчка), символьное имя (третья строчка), информация об авторе и времени создания тега (четвертая строчка), а ниже - сообщение тега.

Команда создания подписанного тега очень похожа на команду создания обычного тега, просто вместо параметра -a надо передать параметр -s. К сожалению именно эта часть не будет воспроизводиться у читателей, так как у каждого должен быть свой собственный GPG-ключ для подписи. Приведу лишь результаты выполнения команды:

$ faketime -t 200001010000 git-tag -m 'Test annotated tag' -s signed_tag lighttag
$ git-cat-file tag signed_tag
object 717c935c292fee3dca4c2e5f335f27b657895368
type blob
tag signed_tag
tagger Git Guts <gitguts@localhost> 946674000 +0300

Test annotated tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkf47VMACgkQ8SRmhxtswwQ53wCdHIGaU1ulxud4cUxWVp2pjU1d
358AnAu0Xlti6ZhCSfp9/YToFd//ipcS
=BQ9s
-----END PGP SIGNATURE-----

Как видно, тут к сообщению добавилась подпись, созданная при помощи моего ключа.

Проверить, каким ключом был подписан коммит, можно с помощью git-tag -v

$ git-tag -v signed_tag
object 717c935c292fee3dca4c2e5f335f27b657895368
type blob
tag signed_tag
tagger Git Guts <gitguts@localhost> 946674000 +0300

Test annotated tag
gpg: Подпись создана Вск 06 Апр 2008 19:33:39 MSD ключом DSA с ID 1B6CC304
gpg: Действительная подпись от "Damir Shayhutdinov <damir@altlinux.ru>"

Вот так!

Удалять теги можно с помощью git-tag -d, это я оставляю на самостоятельную работу.

Что-то я сам не ожидал что получится так много, поэтому описание синтаксиса ссылок git-rev-parse оставлю на потом.

Мысли вслух

Fri, 04 Apr 2008 07:39:30 GMT

Основная проблема проприетарного софта - что там к партнерам по бизнесу относятся как к покупателям. "Все что угодно за ваши деньги".

Основная проблема открытого софта - что там к покупателям относятся как к партнерам по бизнесу. "Тебе надо - ты и делай".

Git Guts (part 6)

Wed, 19 Mar 2008 20:08:48 GMT

SHA1-имена объектов как уникальные идентификаторы - это конечно удобно. Для роботов. Люди как-то привыкли называть друг друга по коротким именам, а не по кодам ДНК.

Символьные имена объектов в git называются ссылка (references), и хранятся в каталоге .git/refs.

Делятся они на три типа:

Теги (tags) - символьные имена любых объектов из базы, которые не меняются со временем. Расположены в .git/refs/tags/

Ветки (heads, branches) - символьные имена объектов-коммитов, которые меняются при добавлении нового коммита в цепочку. Расположены в .git/refs/heads/

Удаленные ветки (remotes) - ветки специального вида, которые предназначены для слежения за ветками (heads) в других репозитариях. Лежат в .git/refs/remotes/

Кроме этого, есть несколько специальных ссылок, которые по историческим соображениям лежат вне каталога .git/refs и их названия пишутся В РЕГИСТРЕ БЛОНДИНОК. Из всех БЛОНДИНОЧНЫХ ссылок для пользователей наиболее важными являются HEAD, ORIG_HEAD и MERGE_HEAD.

HEAD - это особая ссылка, она показывает на коммит, который соответствует рабочей копии. Если быть точным, это не просто ссылка на коммит, это ссылка на "текущую ветку".

Хватит теории, пора иллюстрировать. Создаем простой репозитарий и попробуем те самые высокоуровневые инструменты, которыми раньше не пользовались.

$ mkdir ~/tmp/gitguts6
$ cd ~/tmp/gitguts6
$ git-init
Initialized empty Git repository in .git/
$ git-mktree </dev/null
4b825dc642cb6eb9a060e54bf8d69288fbee4904
$ TREE=4b825dc642cb6eb9a060e54bf8d69288fbee4904
$ export GIT_AUTHOR_NAME="Git Guts"
$ export GIT_AUTHOR_EMAIL="gitguts@localhost"
$ export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
$ export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
$ echo "Первый коммит" | iconv -t utf-8 | faketime -t 200001010000 git-commit-tree $TREE
e678a27ffe7b84211f09b0e397b1c6e287aee392

Итак, был создан новый коммит с пустым деревом. Теперь создадим символьное имя для этого коммита - пусть это будет имя "refs/heads/master". Для этого надо лишь создать обычный файл .git/refs/heads/master и записать в него SHA1-имя коммита. Примерно так:

$ echo e678a27ffe7b84211f09b0e397b1c6e287aee392 > .git/refs/heads/master
$ ln -sf refs/heads/master .git/HEAD

Как видно из примера, я создал ссылку-ветку refs/heads/master, после чего сделал интересную операцию - символическую ссылку .git/HEAD на эту ветку.

Новую созданную ветку может показать команда git-branch:

$ git-branch
* master

Звездочка около master означает что сейчас ссылка HEAD указывает именно на эту ветку.

Чтобы увидеть, как сменой ссылки HEAD git может "переключаться" между ветками, создадим вторую ветку, указывающую на тот же коммит:

$ echo e678a27ffe7b84211f09b0e397b1c6e287aee392 > .git/refs/heads/other
$ git-branch
* master
  other
$ ln -sf refs/heads/other .git/HEAD
$ git-branch
  master
* other

Мы видим как простым переставлением символьной ссылки .git/HEAD выбирается "текущая" ветка.

После того, как было создано символьное имя объекта, можно получить по нему SHA1-имя с помощью команды git-rev-parse:

$ git-rev-parse refs/heads/master
e678a27ffe7b84211f09b0e397b1c6e287aee392
$ git-rev-parse refs/heads/other
e678a27ffe7b84211f09b0e397b1c6e287aee392

Вместо refs/heads/master можно использовать heads/master или master. Также работают БЛОНДИНИСТЫЕ ссылки типа HEAD:

$ git-rev-parse HEAD
e678a27ffe7b84211f09b0e397b1c6e287aee392

Используя git-rev-parse и задание ссылок, можно произвести и простую операцию "коммит в ветку", с которой обычно начинается знакомство с git. Вот эта операция, пошагово:

$ PARENT=`git-rev-parse HEAD` # SHA1 текущего коммита
$ echo "Коммит в ветку other" | iconv -t utf-8 | faketime -t 200001010100 git-commit-tree $TREE -p $PARENT # создаем новый коммит, используя в качестве родителя коммит HEAD
283f22289f768361b854a78f1764dc7f1bd9b822
$ echo 283f22289f768361b854a78f1764dc7f1bd9b822 > .git/HEAD # переставляем ссылку HEAD на новый коммит
$ git-branch # смотрим, по прежнему ли мы на ветке other?
  master
* other

Заметили магию? Из-за того, что .git/HEAD - символическая ссылка на .git/refs/heads/other, запись SHA1 нового коммита в .git/HEAD на самом деле записывает новый коммит в refs/heads/other, затирая предыдущее значение. Теперь ссылка refs/heads/other указывает на новый коммит.

Вот схема:

Было:
HEAD -> refs/heads/other -> старый коммит
Стало:
HEAD -> refs/heads/other -> новый коммит -> старый коммит

То, что раньше пришлось делать вручную - теперь делается через механизм веток и HEAD! Для того, чтобы добавить новый коммит в ветку - надо просто повторить вышеуказанную процедуру. Можно даже сделать это в одну строчку, и при этом совсем избежать указаний SHA1.

$ echo "Еще один коммит в ветку other" | iconv -t utf-8 | faketime -t 200001010200 git-commit-tree $TREE -p `git-rev-parse HEAD` > .git/HEAD # магическая строчка, коммитящая в ветку
$ PAGER=cat git-log --pretty=oneline # git-log без указания коммита показывает историю HEAD
afd309cb9fe66dc314ed54c272a2d26a1b7a01be Еще один коммит в ветку other
283f22289f768361b854a78f1764dc7f1bd9b822 Коммит в ветку other
e678a27ffe7b84211f09b0e397b1c6e287aee392 Первый коммит

Вот так - в ветке other теперь было создано уже три коммита.

Если же теперь переставить ссылку HEAD на refs/heads/master, точно такой же процедурой можно добавлять коммиты в ветку master:

$ ln -sf refs/heads/master .git/HEAD
$ git-branch
* master
  other
$ echo "Теперь коммит в ветку master" | iconv -t utf-8 | faketime -t 200001010300 git-commit-tree $TREE -p `git-rev-parse HEAD` > .git/HEAD
$ PAGER=cat git-log --pretty=oneline
22339820c0dd6758be9cd940db0306d4020f7c9f Теперь коммит в ветку master
e678a27ffe7b84211f09b0e397b1c6e287aee392 Первый коммит

Ну и под занавес - посмотрите как эти ветки выглядят в gitk.

$ gitk --all

Параметр --all говорит gitk показывать все символьные ссылки, а не только те, которые доступны из HEAD. Поэтому мы увидим все две ветки, которые были созданы:

В следующем выпуске я расскажу про тэги, а также про продвинутые возможности программы git-rev-parse, которые позволяют "ходить по ссылкам".

Tue, 18 Mar 2008 13:05:02 GMT

Очередной дятел убил сибя апстену (чувствительным людям не смотреть)

see more crazy cat pics

via http://icanhascheezburger.com/

distrsync

Tue, 04 Mar 2008 20:54:11 GMT

Сегодня в разговоре на канале #altlinux в голове наконец-то оформилась идея, как можно организовать пиринговое (p2p) распространение репозитариев Linux вообще, и репозитариев ALT Linux в частности. Пока рабочее название для этого протокола взаимодействия - distrsync.

Я буду потихоньку выкладывать, как будет время, свои мысли по поводу этого протокола.

Условия и цель разработки протокола

Ни для кого не секрет, что обилие достаточно дешевых и высокоскоростных каналов связи сделало пиринговые сети чрезвычайно популярными в мире. Если обычная архитектура централизованных сетей при повышении количества клиентов начинает испытывать затруднения, то распределенная структура пиринга позволяет сети масштабироваться в чрезвычайно больших пределах. В связи с этим любые централизованные каналы распространения популярной информации целесообразно дополнять или заменять децентрализованными.

Протокол distrsync предполагается для дополнения/замены протокола rsync, который прекрасно зарекомендовал себя в качестве средства синхронизации больших объемов изменяющихся данных по сети. К сожалению, протокол rsync является централизованным, и обладает всеми недостатками централизованных систем:

Скорость синхронизации зависит от пропускной способности канала сервера, и делится между всеми клиентами протокола.

Протокол rsync также создает сильную загрузку подсистемы ввода-вывода как клиента, так и сервера (активная работа требуется для определения, что именно надо передавать). Эта скорость ввода-вывода также делится между всеми клиентами протокола.

Создание системы периодически синхронизируемых зеркал помогает частично бороться с этими недостатками, путем искусственного балансирования нагрузки по нескольким серверам. В такой системе задача балансировки решается на стороне клиента (как правило, выбирается ближайшее географически зеркало с неизвестным режимом синхронизации с основным). Поэтому часть зеркал остаются недогруженными, а часть - перегруженными.

Система зеркал может быть несинхронизованной, на каких-то зеркалах может быть устаревшая информация. Для проверки устаревания информации используют либо полное сканирование синхронизируемой области, либо какие-то внепротокольные решения, например файлы с датой последнего обновления зеркала. Задача поддержки этого файла в актуальном состоянии ложится на администратора зеркала.

Надежность централизованной системы зависит от надежности зеркал. Перегруженные зеркала обладают пониженной надежностью, а так как обычно на этих зеркалах лежит самая свежая информация, отказ зеркала приводит к невозможности клиентов получить свежие данные.

Протокол distrsync задумывается для следующих масштабов задач синхронизации:

Общий объем синхронизируемых данных - порядка десятков гигабайт.

Количество синхронизируемых файлов - порядка нескольких тысяч.

Количество одновременно синхронизирующих клиентов - порядка десятков тысяч.

Скорость устаревания информации - порядка 5-10% в день.

Отказоустойчивость системы - система должна функционировать при отказе 50% центральных узлов, координирующих обмен данными

Также протокол может должен поддерживать следующие возможности:

контроль целостности синхронизируемых данных и невозможность фальсификации данных со стороны клиентов или центральных узлов

возможность выборочных синхронизации данных по заданным клиентом критериям

обмен данными между несинхронизованными клиентами (или частично синхронизованными, aka "докачка")

возобновление синхронизации при временном отказе сети без потери уже принятой информации

поддержка IPv6

принципиальная кроссплатформенность (по крайней мере POSIX-системы и Windows)

В целях удобства использования протокол также может поддерживать:

возможность предпочтения источников данных (клиентов и центральных узлов) по географическим, сетевым или другим признакам

стимулирование обмена данных между клиентами после завершения синхронизации (например, используя систему распределенных рейтингов)

противодействие попыткам намеренной фальсификации передаваемых данных

При проектировании не делалось никаких попыток гарантировать:

анонимность при передаче данных

совместимость с существующими технологиями децентрализованного обмена данными

Обзор существующих решений

Узкое место существующих централизованных решений - количество одновременно синхронизирующих клиентов. Я не знаю протоколов, которые бы могли масштабироваться в указанных пределах (кроме разве что кластерной Samba).

Рассмотрим теперь существующие и активно применяемые пиринговые решения:

BitTorrent
Протокол BitTorrent хорошо масштабируется по общему объему передаваемых (зеркалируемых) данных (возможны раздачи размером в десятки гигабайт), и поддерживает десятки тысяч одновременно синхронизирующих клиентов. Также BitTorrent за счет "склеивания" всех передаваемых файлов в один общий массив информации обеспечивает равномерность закачивания и поддержку большого количества зеркалируемых файлов. Размер метафайла, содержащего информацию для скачивания, растет пропорционально количеству файлов, но не очень сильно, позволяя держать размер всего метафайла в пределах 1Mb.

К сожалению, протокол не поддерживает обновление синхронизирующейся информации. Изменение даже одного байта информации ведет к несовпадению контрольной суммы одного блока информации, и как следствие, к несовпадению контрольной суммы всего метафайла. Именно по этой контрольной сумме производится поиск клиентов для координации обмена между ними. Следовательно, клиенты, синхронизирующие обновленные данные, не смогут использовать информацию от клиентов, синхронизирующих старые данные.

Таким образом, в задачах распространения изменяемых данных (например, обновляемых репозитариев Linux), протокол BitTorrent эффективно использоваться не может. Для неизменяемых данных (образов дисков, необновляемых репозитариев), использование BitTorrent может быть предпочтительнее других каналов распространения из-за популярности и развитости технологии.

Система BitTorrent также страдает от централизованности компонента, координирующего обмен (трекера, tracker). При отказе трекера эффективный обмен данными невозможен. Частично эту проблему решает поддержка DHT (Distributed Hash Table), а также добавление нескольких трекеров (поиск трекеров остается задачей клиентов).

Direct Connect (DC++)
Если верить википедии, этот протокол испытывает трудности при масштабировании по количеству клиентов, за счет включения широковещательных функций (например, чат). Поэтому хабы сети (hubs) могут быть перегруженными и отказывать, оставляя клиентов без возможности координирования.

Для задач синхронизации функции чата не нужны, так что требуется более пристальное изучение возможностей масштабирования. Закрытость оригинального протокола DC уменьшает привлекательность протокола.

Другие сети пока не рассматривал, подскажите куда стоит посмотреть

Сизиф и море^Wкошки

Tue, 22 Jan 2008 14:29:09 GMT

moar funny pictures

Git Guts (Part 5)

Sun, 20 Jan 2008 18:41:39 GMT

Для тех, кто раньше работал только с CVS или CVS++ (ну то есть Subversion), концепция коммитов-слияний (merge) может оказаться не очень понятной. Так что я решил обратиться к классике для иллюстрации слияний.

Помните, Николай Васильевич Гоголь, "Женитьба"... Если кто позабыл, я напомню монолог Агафьи Тихоновны (полный текст см. тут: http://az.lib.ru/g/gogolx_n_w/text_0080.shtml).

Право, такое затруднение -- выбор! Если бы еще один,
два человека, а то четыре. Как хочешь, так и выбирай. Никанор Иванович
недурен, хотя, конечно, худощав; Иван Кузьмич тоже недурен. Да если сказать
правду. Иван Павлович тоже хоть и толст, а ведь очень видный мужчина. Прошу
покорно, как тут быть? Балтазар Балтазарыч опять мужчина с достоинствами. Уж
как трудно решиться, так просто рассказать нельзя, как трудно! Если бы губы
Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять
сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй,
прибавить к этому еще дородности Ивана Павловича -- я бы тогда тотчас же
решилась. А теперь поди подумай! просто голова даже стала болеть.

Бедная Агафья Тихоновна. Ведь в то доисторическое время еще не было современных систем контроля версий, разве что CVS, который был придуман еще во времена динозавров. А ведь задача создания идеального жениха из лучших качеств четырех претендентов - типичная задача слияния!

В нижеприведенном примере я намеренно не буду использовать встроенные в git автоматические системы слияния, чтобы показать внутреннюю кухню. В жизни все будет гораздо проще.

Итак, начнем с создания репозитория и инициализации переменных окружения:

$ mkdir ~/tmp/gitguts5
$ cd ~/tmp/gitguts5
$ git init-init
Initialized empty Git repository in .git/

$ export GIT_AUTHOR_NAME="Git Guts"
$ export GIT_AUTHOR_EMAIL="gitguts@localhost"
$ export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
$ export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"

Теперь создадим файл-заготовку, который мы будем использовать для заполнения наших деревьев - перечень человеческих достоинств, которые ценит Агафья Тихоновна:

$ echo -e "Губы\nНос\nРазвязность\nДородность" > virtues-template
$ cat virtues-template
Губы
Нос
Развязность
Дородность

Обращаю внимание что текст в файле virtues-template записан в системной кодировке. Для того, чтобы была воспроизводимость всех проделанных действий, перед занесением в git я буду переводить текст из системной кодировки в utf-8. На самом деле git не предъявляет никаких требований к кодировке, но тем не менее я бы рекомендовал держать коммиты либо в ASCII (то есть писать их по английски), либо в utf-8, если вы хотите чтобы ваши коммиты читал кто-нибудь вне России.

Итак, следующим этапом будет создание начального коммита. Его дерево будет состоять из одного файла - virtues, который будет аналогичен файлу virtues-template, только переведен в utf-8 для воспроизводимости. Почему начальный коммит должен быть именно таким - я объясню позже.

Итак, создание начального коммита (ничего нового для тех, кто внимательно читал предыдущие выпуски):

$ iconv -t utf-8 < virtues-template > virtues
$ git-hash-object -w virtues
111f008f40b32148b325098b0b3ad1fe46df0aef

$ echo -e "100644 blob 111f008f40b32148b325098b0b3ad1fe46df0aef\tvirtues" | git-mktree
f387e3ef43d001f614ef1a5a8c6ac4a0996c7c3c

$ echo "Обычный человек" | iconv -t utf-8 | faketime -t 200001010000 git-commit-tree f387e3ef43d001f614ef1a5a8c6ac4a0996c7c3c
6173ad1924d1221b82fe940e96eca4ec914b4b6c

Итак, у нас есть начальный коммит (без предков), с сообщением "Обычный человек". Зачем? Потому что именно так работает автоматическое слияние. Ему нужен "общий предок" всех сливаемых коммитов, чтобы понять, что у них общее, а что - различается.

Теперь давайте создадим коммиты, соответствующие женихам Агафьи Тихоновны: Никанор Иваныч, Иван Кузьмич, Балтазар Балтазарыч и Иван Павлович. Отличаться эти коммиты будут тем, что вместо

Губы
Нос
Развязность
Дородность

будет

Губы Никанора Иваныча
Нос Никанора Иваныча
Развязность Никанора Иваныча
Дородность Никанора Иваныча

Ну, вы надеюсь поняли. Добавлять "Никанора Иваныча" в конце каждой строчки мы будем с помощью простейшего скрипта на sed, вот иллюстрация:

$ sed 's/$/ Никанора Иваныча/' virtues-template
Губы Никанора Иваныча
Нос Никанора Иваныча
Развязность Никанора Иваныча
Дородность Никанора Иваныча

Итак, создадим эти четыре коммита:

Никанор Иваныч:

$ PARENT="6173ad1924d1221b82fe940e96eca4ec914b4b6c"
$ sed 's/$/ Никанора Иваныча/' virtues-template | iconv -t utf-8 > virtues-NI
$ git-hash-object -w virtues-NI
929db472b24b02eb991257c26376609e4da6966b

$ echo -e "100644 blob 929db472b24b02eb991257c26376609e4da6966b\tvirtues" | git-mktree
0ade4416fb17c0eb8037265a2e0405db102164eb
$ echo "Никанор Иваныч" | iconv -t utf-8 | faketime -t 200001010100 git-commit-tree 0ade4416fb17c0eb8037265a2e0405db102164eb -p $PARENT
f683f1e38e0339885c5ff31ed3efa6f5060c57b3

Иван Кузьмич:

$ sed 's/$/ Ивана Кузьмича/' virtues-template | iconv -t utf-8 > virtues-IK
$ git-hash-object -w virtues-IK
b4bd4d3eae566ac8d58a5a4dc8dccf06a8a8602c

$ echo -e "100644 blob b4bd4d3eae566ac8d58a5a4dc8dccf06a8a8602c\tvirtues" | git-mktree
f7509f166ee816355654e1fd8b21bfa616272d38

$ echo "Иван Кузьмич" | iconv -t utf-8 | faketime -t 200001010100 git-commit-tree f7509f166ee816355654e1fd8b21bfa616272d38 -p $PARENT
ff7a5afbdf16e8ade231e1adec6e9a44838c44d0

Балтазар Балтазарыч:

$ sed 's/$/ Балтазар Балтазарыча/' virtues-template | iconv -t utf-8 > virtues-BB
$ git-hash-object -w virtues-BB
66d2a243ba12d21ba95ce44e757681a4d4e05428

$ echo -e "100644 blob 66d2a243ba12d21ba95ce44e757681a4d4e05428\tvirtues" | git-mktree
f56b93f223725f10602f0c404114671ed04ad743

$ echo "Балтазар Балтазарыч" | iconv -t utf-8 | faketime -t 200001010100 git-commit-tree f56b93f223725f10602f0c404114671ed04ad743 -p $PARENT
c89d03e1e07c2a2fdb52bc85615bed628b4de202

Иван Павлович:

$ sed 's/$/ Ивана Павловича/' virtues-template | iconv -t utf-8 > virtues-IP
$ git-hash-object -w virtues-IP
9c9c6c6f479e13ce061e82863c17e3bc03ce8960
$ echo -e "100644 blob 9c9c6c6f479e13ce061e82863c17e3bc03ce8960\tvirtues" | git-mktree
3d2459538e8ff3809d557758649a5a9c9393c124
$ echo "Иван Павлович" | iconv -t utf-8 | faketime -t 200001010100 git-commit-tree 3d2459538e8ff3809d557758649a5a9c9393c124 -p $PARENT
2762e87bf446e3f886996d8e984b69a6204b4305

Дерево этих коммитов будет выглядеть в gitk примерно так:

gitk 2762e87bf446e3f886996d8e984b69a6204b4305\
    c89d03e1e07c2a2fdb52bc85615bed628b4de202\
    ff7a5afbdf16e8ade231e1adec6e9a44838c44d0\
    f683f1e38e0339885c5ff31ed3efa6f5060c57b3

Каждый из женихов отличается от общего предка - "Обычного человека" персонализированным набором качеств.

Агафья Тихоновна хотела бы создать идеального жениха, скомбинировав эти персонализированные отличия. В этом нам поможет слияние.

В классическом случае операция слияния - это

Формирование нового дерева, которое каким-то образом включает в себя изменения, произошедшие в сливаемых ветках со времени их общего предка.

Формирование нового коммита с этим деревом, в качестве предков которого указаны все сливаемые коммиты

Автоматическая система слияния git в многих случаях может сама "слить" ветки, без участия пользователя. Например, если изменения в сливаемых ветках затрагивают разные файлы, или один и тот же файл, но изменяемые строчки не пересекаются. Новое дерево в таком случае формируется автоматически.

В нашем же запущенном случае в каждом коммите-женихе все строчки изначального "Обычного человека" заменены - поэтому при слиянии получается конфликт. Например, чьи губы должны быть у результата слияния - Никанора Иваныча или Балтазара Балтазарыча? Или может Ивана Павловича?

В таких ситуациях единственное решение принять должен человек. В нашем случае - Агафья Тихоновна. Благодаря Гоголю Агафья уже разрешила все конфликты слияния, постановив, что у идеального жениха должно быть:

Губы Никанора Иваныча

Нос Ивана Кузьмича

Развязность Балтазара Балтазарыча

Дородность Ивана Павловича

Вот с таким вот идеальным деревом мы и создадим коммит-слияние:

$ echo "Губы Никанора Иваныча" > ideal-template
$ echo "Нос Ивана Кузьмича" >> ideal-template
$ echo "Развязность Балтазара Балтазарыча" >> ideal-template
$ echo "Дородность Ивана Павловича" >> ideal-template
$ cat ideal-template
Губы Никанора Иваныча
Нос Ивана Кузьмича
Развязность Балтазара Балтазарыча
Дородность Ивана Павловича

$ iconv -t utf-8 <ideal-template >ideal
$ git-hash-object -w ideal
aaad89b8229eab40cde73cd3afe05cfb689f8a85
$ echo -e "100644 blob aaad89b8229eab40cde73cd3afe05cfb689f8a85\tvirtues" | git-mktree 
3bb4ea25e93d5962d6a568330aea334161d55009
$ echo "Идеальный жених Агафьи Тихоновны" | iconv -t utf-8 | faketime -t 200001010200 git-commit-tree 3bb4ea25e93d5962d6a568330aea334161d55009\
    -p 2762e87bf446e3f886996d8e984b69a6204b4305\
    -p c89d03e1e07c2a2fdb52bc85615bed628b4de202\
    -p ff7a5afbdf16e8ade231e1adec6e9a44838c44d0\
    -p f683f1e38e0339885c5ff31ed3efa6f5060c57b3
31e839af8dbd1315ceaa9dbbcc2c2c71ff91d797

Как видно, от обычных коммитов с одним предком, коммит-слияние отличается лишь тем, что у него несколько предков, каждый указан как -p <SHA1>

Посмотрим же на результат в gitk:

gitk 31e839af8dbd1315ceaa9dbbcc2c2c71ff91d797

Как видно, коммит-слияние в gitk графически отображается как соединение всех веток в одну точку. В классическом случае (без использования всяческих хаков или низкоуровневых команд), когда git видит коммит-слияние, он считает что все изменения, которые были в сливаемых ветках, в точке слияния были согласованы, и все конфликты поправлены.

Если в дальнейшем сливаемые ветки будут развиваться дальше по отдельности, то при очередном слиянии git будет считать коммит-слияние общим предком, и конфликтовать будут только изменения, произошедшие после коммита-слияния.

Итак, подведем итоги:
Коммит-слияние с технической точки зрения ненамного сложнее обычного коммита. Главной проблемой при слияниях является "Право, такое затруднение -- выбор!", говоря словами Агафьи Тихоновны. Во многих случаях этот выбор может сделать сам git, предоставляя несколько стратегий автоматического слияния. Но в сложных случаях без помощи человека в решении конфликтов не обойтись.

Обзор стратегий автоматического слияния я пожалуй оставлю на потом, а в следующем выпуске расскажу о текстовых ссылках (refs), которые значительно облегчают работу с git. Именно они, а не SHA1 имена объектов, используются для повседневной работы в git. Stay tuned!

Git Gems

Mon, 12 Nov 2007 19:12:24 GMT

Это ни в коем случае не заменитель очередного выпуска Git Guts, просто хочется поделиться одним на мой взгляд изящным применением git-remote.

Предположим, что вы работает в своем git-репозитории. Напатчили несколько веток, и вдруг - решили все переделать. Вернуть как было.

Можно конечно воспользоваться reflog-ом
например, вернуть ветку master на значение, которое было 3 часа назад, можно через

git-checkout master
git-reset --hard 'master@{3 hours ago}'

И так для всех веток. Это в том случае если вы помните, что начали патчить 3 часа назад.

Если же вы, как и я, сильно увлекаетесь и забываете о времени - это вряд ли подойдет.

На этот случай можно сделать хитрый ход конем. Через git-remote создается "удаленный репозиторий", который на самом деле совпадает с текущим репозиторием. Вот как это делается.

git-remote add backup `pwd`
git-fetch -f backup

После выполнения git-fetch -f backup все существующие ветки будут сохранены в refs/remotes/backup/<имя ветки>

И "восстановить" бранч master из бэкапа можно командой

git-checkout master
git-reset --hard backup/master

Еще раз: бэкап делается через git-fetch -f backup, а восстановление веток делается путем git-reset --hard backup/branch.

Этот метод можно развивать, создавая несколько бэкапов. Каждый такой "псевдо-удаленный" репозиторий представляет собой мгновенный слепок всех веток на момент git-fetch -f.

В дополнение к бэкапам можно использовать и "корзины". Например, перед откатом на бэкап вам возможно захочется сохранить текущие наработки во всех ветках, на всякий случай - вдруг пригодятся. Не проблема - создаете псевдоудаленный репозиторий "recyclebin", делаете git-fetch -f recyclebin - и все ваши наработки сохраняются в удаленных ветках этого репозитория. В дальнейшем их можно вернуть, сделать cherry-pick полезных патчей оттуда и т.п.

Также как и бэкапов, корзин можно сделать сколько угодно.

Git Guts (Part 4)

Mon, 22 Oct 2007 19:41:49 GMT

Git не был бы системой контроля версий, если бы не позволял хранить историю изменений деревьев.

Для хранения истории в git используются специальные объекты-commit'ы. Каждому коммиту соответствует ровно одно дерево. Коммиты также хранят информацию о "предках" этого дерева - то есть ссылки на т.н. родительские коммиты. Можно считать, что коммит указывает, из каких деревьев (их может быть несколько) произошло текущее дерево, а также кто в этом виноват (автор коммита) и по какой причине (сообщение коммита).

У самого первого коммита в репозитории не может быть предков. Он считается начальным коммитом, и считается что до него ничего не было. В репозитории git обычно бывает только один начальный коммит, а все остальные происходят из него. Можно считать начальный коммит Адамом и Евой :) У большинства коммитов предок всего один, поэтому часто история коммитов линейна. Авраам родил Исаака, Исаак родил Иакова, Иаков родил Иуду и т.д. :)

Бывает, что несколько коммитов происходят от одного предка. В этом месте в истории появляется "развилка" - история начинает делиться на ветви ("колена", если продолжать аналогию с Библией).

Но бывают еще коммиты, у которых несколько родителей. Это т.н. коммиты-слияния (merges), и в общем-то, количество родителей у коммита не ограничено. Это действие противоположно вышеописанной "развилке", и объединяет ранее разделенные ветви. Так, породнились бы Капулетти и Монтекки, если бы Вильяму Шекспиру захотелось бы устроить в "Ромео и Джульетте" хэппи-энд.

Но довольно лирики. Если говорить формально, то сам объект-коммит - это простой текст в строго определенном формате. У каждого коммита есть соответствующее дерево (первая строчка), далее перечисляются родители (каждый родитель на отдельной строчке), а дальше указываются "автор" коммита и время создания коммита.
После этого указывается т.н. "committer" - человек, который записал коммит в историю репозитория. Вместе с committer записывается и время, когда коммит был записан в историю. После чего оставшиеся строки занимает сообщение о коммите - произвольный текст, который указал автор при создании коммита.

Обычно поля committer и author совпадают, если автор сразу же после создания коммита записывает его в репозиторий. Но бывает и другая ситуация, когда один человек создает коммит, а другой применяет этот коммит к своему репозиторию. Тогда author и committer будут совершенно разными людьми. И committer и author указываются в формате Имя <email>, который считается стандартным форматом для задания адреса электронной почты.

Создать объект-коммит можно с помощью команды git-commit-tree.

У этой команды один обязательный параметр - SHA1 объекта-дерева, соответствующего коммиту. Также может быть несколько необязательных параметров, перечисляющих родителей коммита.

На вход (stdin) этой команде надо подать сообщение коммита. Остальные поля (author и commiter) команда заполняет сама. Если определенным образом не сконфигурировать git, по умолчанию в качестве имени автора будет использоваться имя текущего пользователя, а в качестве адреса электронной почты - <login текущего="текущего" пользователя@имя="пользователя@имя" хоста="хоста">. Также в качестве даты создания коммита и записи его в историю, будет использоваться текущая дата.

Ну что долго объяснять, вот вам пример:

$ mkdir ~/tmp/gitguts4
$ cd ~/tmp/gitguts4
$ git-init
Initialized empty Git repository in .git/

$ echo "file1" > file1
$ echo "file2" > file2

$ git-hash-object -w file1
e2129701f1a4d54dc44f03c93bca0a2aec7c5449

$ git-hash-object -w file2
6c493ff740f9380390d5c9ddef4af18697ac9375

$ echo -e "10644 blob e2129701f1a4d54dc44f03c93bca0a2aec7c5449\tfile1
10644 blob 6c493ff740f9380390d5c9ddef4af18697ac9375\tfile2" | git-mktree

eaa27839f1ccaa6e087202ec96c479ee2c93b71e

$ export GIT_AUTHOR_NAME="Git Guts"
$ export GIT_AUTHOR_EMAIL="gitguts@localhost"
$ export GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
$ export GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"

$ echo "Initial commit" | faketime -t 200001010000 git-commit-tree  eaa27839f1ccaa6e087202ec96c479ee2c93b71e

a215c9607c843ff00bc1490fb51271b6211070a2

Обратите внимание - я использовал задание автора и коммитера через переменные окружения, а также использовал faketime для того, чтобы задать время создания коммита и время сохранения его в репозитории. Дело в том, что если вы попытаетесь повторить мои действия, и не будете использовать переменные окружения и faketime, то в коммите будет другое время, и другие авторы/коммитеры, и вы не сможете полностью воспроизвести последующие действия, так как у коммитов будут другие имена и другое содержимое.

Посмотреть содержимое созданного объекта можно, используюя утилиту git-cat-file

$ git-cat-file commit a215c9607c843ff00bc1490fb51271b6211070a2
tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e
author Git Guts <gitguts@localhost> 946674000 +0300
committer Git Guts <gitguts@localhost> 946674000 +0300

Initial commit

Ну, думаю не стоит объяснять, где что находится в этом объекта - все и так очевидно. Созданный коммит не имеет предков - то есть является сиротой. :) Давайте создадим ему потомков, чтобы было веселее. Для того, чтобы указать родителя коммита, в параметры git-commit-tree надо добавить -p <sha1 родителя>, ну например как показано в следующем примере:

$ echo "Abraham" | faketime -t 200001010100 git-commit-tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e -p a215c9607c843ff00bc1490fb51271b6211070a2

09e01781c4c8245acd0728184d7cb8d9c7579901

$ git-cat-file commit 09e01781c4c8245acd0728184d7cb8d9c7579901
tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e
parent a215c9607c843ff00bc1490fb51271b6211070a2
author Git Guts <gitguts@localhost> 946677600 +0300
committer Git Guts <gitguts@localhost> 946677600 +0300

Abraham

Итак, Авраам рожден :) Видите, в коммите добавилось поле parent, с указанием родительского коммита. Добавим же Исаака - сына его :) (для этого укажем в поле "родитель" SHA1 Авраама).

$ echo "Isaac" | faketime -t 200001010200 git-commit-tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e -p 09e01781c4c8245acd0728184d7cb8d9c7579901

420a3454070a1767c3fe7107f9dc753d8ff3722c

$ git-cat-file commit 420a3454070a1767c3fe7107f9dc753d8ff3722c
tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e
parent 09e01781c4c8245acd0728184d7cb8d9c7579901
author Git Guts <gitguts@localhost> 946681200 +0300
committer Git Guts <gitguts@localhost> 946681200 +0300

Isaac

Для простоты для всех создаваемых коммитов я указываю одно и то же дерево. В большинстве реальных случаев деревья таки будут чем-то отличаться.

Давайте теперь посмотрим на историю вновь созданного Исаака. Просмотром истории в git занимается программа-историк git-log.

$ PAGER=cat git-log 420a3454070a1767c3fe7107f9dc753d8ff3722c 
commit 420a3454070a1767c3fe7107f9dc753d8ff3722c
Author: Git Guts <gitguts@localhost>
Date:   Sat Jan 1 02:00:00 2000 +0300

    Isaac

commit 09e01781c4c8245acd0728184d7cb8d9c7579901
Author: Git Guts <gitguts@localhost>
Date:   Sat Jan 1 01:00:00 2000 +0300

    Abraham

commit a215c9607c843ff00bc1490fb51271b6211070a2
Author: Git Guts <gitguts@localhost>
Date:   Sat Jan 1 00:00:00 2000 +0300

    Initial commit

Я использовал PAGER=cat, чтобы git-log не запускал для просмотра истории команду less (ну или что там у вас поставлено вместо $PAGER), а просто тупо вываливал информацию в терминал.

Итак, по выводу истории видно, что от начального коммита произошел Авраам, а от Авраама - Исаак :)

Продолжим наши уроки Ветхого завета и продемонстрируем "развилку". У Исаака, как известно, было два сына - Исав и Иаков. Исав - старший брат, Иаков - младший. Продемонстрируем это в терминах git.

$ echo "Esau" | faketime -t 200001010300 git-commit-tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e -p 420a3454070a1767c3fe7107f9dc753d8ff3722c
de10f1828d215892dcebd00c4f7738141bfd0df7

$ echo "Jakob" | faketime -t 200001010400 git-commit-tree eaa27839f1ccaa6e087202ec96c479ee2c93b71e -p 420a3454070a1767c3fe7107f9dc753d8ff3722c
f77f5c2466a3f8674d3ec8785b13a910d32e5a75

Вот, таким вот макаром были рождены эти два брата. Для того, чтобы отобразить их отношения, обычного текстового формата недостаточно. Поэтому будем использовать графическую программу gitk. В качестве параметров я перечислил SHA1-имена братьев.

$ gitk de10f1828d215892dcebd00c4f7738141bfd0df7 f77f5c2466a3f8674d3ec8785b13a910d32e5a75

Результат работы можно увидеть вот тут:

Как видно, налицо развилочка. В дальнейшем каждая ветвь может получить отдельное развитие.

Ну, в общем, хватит на сегодня.

О таких захватывающих вещах как коммиты-слияния (merges) я, пожалуй, расскажу в следующий раз.

Git Guts (Part 3)

Tue, 14 Aug 2007 11:19:01 GMT

В первой части я уже упоминал, что репозиторий git представляет собой картотеку объектов, объединенных ссылками друг на друга.

Из четырех типов объектов в git (blob, tree, commit, tag) только blob-ы не могут содержать ссылки. Все остальные объекты, по сути, являются просто ссылками либо на blob-ы, либо на другие ссылки.

Мы уже знаем, что blob-ы включают в себя только содержание файла, но не его имя, или режимы доступа. Вся информация об именах содержится в объектах-деревьях (tree). Фактически, деревья аналогичны понятию "каталог" в файловой системе, так же как blob-ы аналогичны понятию inode.

Объекты-деревья могут хранить внутри себя как ссылки на blob-ы, так и ссылки на другие объекты-деревья. В результате можно построить иерархию деревьев, аналогичную иерархии каталогов и файлов.

Объект-дерево представляет собой список элементов, состоящих из четырех полей:

mode (режим доступа) - представляет собой права UNIX на объект-ссылку, плюс несколько дополнительных битов, позволяющих хранить в гите символические ссылки. Записывается в виде шести цифр, из которых первые три описывают тип объекта, а оставшиеся - права UNIX. Правда мне ни разу не удалось увидеть, чтобы значение третьей цифры было отлично от нуля, так что я не знаю что она означает.
Первая цифра - 1 для файлов и символических, 0 для директорий.
Вторая цифра - 0 для файлов, 2 для символических ссылок, 4 - для директорий

Тип объекта, на который ссылается элемент списка. Может быть blob или tree.

SHA1 хеш объекта. Собственно, это и является ссылкой, так как однозначно определяет объект в репозитории git.

имя объекта. Имя файла для blob-ов, имя директории для tree.

Объект-дерево после создания получает свое имя-хеш, и может быть после этого включен в другие деревья.

Создать новый объект-дерево можно с нуля, используя команду git-mktree. Ей на вход (stdin) надо передать текстовый список, в котором каждая строчка описывает один элемент. Первые три поля должны быть разделены пробелами, а последнее - имя объекта - должно быть отделено табом.

Вот пример:

$ mkdir ~/tmp/gitgut3
$ cd ~/tmp/gitgut3
$ git-init
Initialized empty Git repository in .git/

$ echo "File1" > file1
$ echo "File2" > file2

$ git-hash-object -w file1
03f128cf48cb203d938805e9f3e13b808d1773e9
$ git-hash-object -w file2
b973e639605e63466ea5ba09b04a545f16946ca8

$ echo -e "100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9\tfile1
100640 blob b973e639605e63466ea5ba09b04a545f16946ca8\tfile2" | git-mktree

b2efb2a7e48025c4d185080412a6ba1121ee6c59

Как видно из примера, команде git-mktree нужно подать на стандартный вход содержимое создавамого объекта-дерева, что я и сделал командой echo.
Полученный объект-дерево теперь присутствует в базе:

$ ls .git/objects/b2/efb2a7e48025c4d185080412a6ba1121ee6c59 
.git/objects/b2/efb2a7e48025c4d185080412a6ba1121ee6c59

Его содержимое можно посмотреть, используя команду git-ls-tree

$ git-ls-tree b2efb2a7e48025c4d185080412a6ba1121ee6c59     
100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9    file1
100640 blob b973e639605e63466ea5ba09b04a545f16946ca8    file2

Чтобы далеко не уходить, покажу, чем же полезно, что деревья являются именно объектами, с именами-хешами.

Например, если у двух объектов-деревьев одинаковое имя-хеш, что это означает? Что внутренности этих деревьев совпадают! А так как внутренности деревьев - это ссылки на объекты, то это означает что два дерева ссылаются на одни и те же объекты. Которые в свою очередь тоже могут быть деревьями или блобами. Таким образом имя-хеш дерева на самом деле идентифицирует не только "файлы в директории", но и все файлы во всех поддиректориях этой директории - одно имя для всех иерархии!

Это свойство позволяет git-у очень быстро производить сравнение деревьев со сколь угодно сложной иерархией, уровнями вложенности и т.д. без чтения собственно содержимого - blob-ов или tree.

Например, я создаю новое дерево, которое отличается от старого дерева b2efb2a7e4... тем, что в содержимое file2 была добавлена дополнительная строчка, а файл file1 переименован в file3.

$ echo Secondline >> file2
$ git-hash-object -w file2
4dd2746869211aedfec0f07afb12a879c09569e7

$ echo -e "100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9\tfile3
100640 blob 4dd2746869211aedfec0f07afb12a879c09569e7\tfile2" | git-mktree

493a5292de0b743e77aa190921da56d33599b59e

$ git-ls-tree 493a5292de0b743e77aa190921da56d33599b59e

100640 blob 4dd2746869211aedfec0f07afb12a879c09569e7    file2
100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9    file3

Давайте посмотрим, как git может легко вычислить разницу между этими деревьями. используя только объекты-деревья.
Для этого сохраним выводы git-ls-tree для каждого дерева в отдельный файл и натравим на них команду diff -u.

$ git-ls-tree b2efb2a7e48025c4d185080412a6ba1121ee6c59 > tree1
$ git-ls-tree 493a5292de0b743e77aa190921da56d33599b59e > tree2
$ diff -u tree1 tree2
--- tree1       2007-08-14 14:55:06 +0400
+++ tree2       2007-08-14 14:55:30 +0400
@@ -1,2 +1,2 @@
-100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9   file1
-100640 blob b973e639605e63466ea5ba09b04a545f16946ca8   file2
+100640 blob 4dd2746869211aedfec0f07afb12a879c09569e7   file2
+100640 blob 03f128cf48cb203d938805e9f3e13b808d1773e9   file3

Итак, видно, что по сравнению с деревом 1 в дереве два исчез file1, у file2 изменился SHA1 хеш, и добавился новый file3.
Также можно заметить, что у удаленного файла file1 и добавленного файла file3 одинаковый SHA1 хеш - отсюда можно сделать вывод, что было произведено переименование из file1 в file3 без изменения содержимого.

Точно такую же работу производит и git, точнее его команда git-diff-tree. Она выводит разницу между двумя деревьями в читабельном для человека виде.

$ git-diff-tree b2efb2a7e48025c4d185080412a6ba1121ee6c59 493a5292de0b743e77aa190921da56d33599b59e
:100644 000000 03f128cf48cb203d938805e9f3e13b808d1773e9 0000000000000000000000000000000000000000 D      file1
:100644 100644 b973e639605e63466ea5ba09b04a545f16946ca8 4dd2746869211aedfec0f07afb12a879c09569e7 M      file2
:000000 100644 0000000000000000000000000000000000000000 03f128cf48cb203d938805e9f3e13b808d1773e9 A      file3

Если git-diff-tree вызывать с ключом -p, то она сгенерирует патч, который будучи применен к tree1, приведет его к tree2.

git-diff-tree -p b2efb2a7e48025c4d185080412a6ba1121ee6c59 493a5292de0b743e77aa190921da56d33599b59e
diff --git a/file1 b/file1
deleted file mode 100644
index 03f128c..0000000
--- a/file1
+++ /dev/null
@@ -1 +0,0 @@
-File1
diff --git a/file2 b/file2
index b973e63..4dd2746 100644
--- a/file2
+++ b/file2
@@ -1 +1,2 @@
 File2
+Secondline
diff --git a/file3 b/file3
new file mode 100644
index 0000000..03f128c
--- /dev/null
+++ b/file3
@@ -0,0 +1 @@
+File1

Как видно по патчу, git-diff-tree не учел, что файл file1 был переименован в file3, и сгенерировал патч так, как будто file1 удалили, и file3 добавили заново.

Но как мы знаем, blob-ы у file1 и file3 совпадают - поэтому можно точно сказать что было переименование. Для того, чтобы git-diff-tree стал обращать на это внимание, ему надо передать ключик -M (detect renames).

Тогда он сгенерирует особый патч-переименование. К сожалению, стандартная команда patch не может прикладывать такие патчи-переименования, так что потребуется прикладывать этот патч к дереву с помощью команды git-apply.

$ git-diff-tree -M -p b2efb2a7e48025c4d185080412a6ba1121ee6c59 493a5292de0b743e77aa190921da56d33599b59e
diff --git a/file2 b/file2
index b973e63..4dd2746 100644
--- a/file2
+++ b/file2
@@ -1 +1,2 @@
 File2
+Secondline
diff --git a/file1 b/file3
similarity index 100%
rename from file1
rename to file3

Итак, объекты-деревья служат для объединения blob-ов и других деревьев в иерархию, аналогичную файловой системе. Деревья хранят биты доступа, хеши содержимого и имена объектов, поэтому между двумя деревьями может быть разница только по этим параметрам.

Такие параметры как времена создания, изменения и доступа файла, а также создатель или владелец файла, в деревьях не записываются. Некоторое подобие такой информации хранят объекты-commit'ы, о которых я расскажу в следующий раз.

А пока вам домашнее задание: создайте пустое объект-дерево (вообще без файлов) и запостите сюда его SHA1

Продолжение следует.

Git Guts (Part 2)

Mon, 13 Aug 2007 17:32:23 GMT

Чтож, если ваш мозг не был зохаван Ктулху во время чтения предыдущего поста, то вы уже знаете, что репозиторий git представляет собой картотеку различных объектов, разложенную по именам-хешам. Объекты бывают четырех типов - blob, tree, commit, tag.

Объекты типа blob(Binary Large Object) - это основа репозитория. Это маленькие безымянные герои. Безымянные в прямом смысле - это просто содержимое, без имени. Если вы добавляете в git файл tutorial.txt с содержимым "Hello, world!", то это результирующий blob-объект будет содержать строчку "Hello, world!" и ни слова о tutorial.txt. Это очень похоже на иноды (inodes), используемые в файловых системах, если вы понимаете о чем я.

Новый blob-объект создается из содержимого файла с помощью команды git-hash-object.

Если вызывать ее без параметров, только с именем файла - то она выведет SHA1 хеш blob-объекта, который будет создан из этого файла. Если же вызвать ее с параметром -w, то соответствующий blob-объект будет записан в базу под именем, соответствующим этому хешу.

Если объект с таким именем уже существует в базе - то он не будет перезаписан. Вспомните, что имя является "отпечатком пальца" объекта, достаточно уникальным. Значит, если у двух объектов одинаковые имена, то у них одинаковые содержимые. Поэтому git не будет перезаписывать blob.

Например, если в гит положить десять абсолютно одинаковых файлов весом 6 мегабайт, то реально в базе будет занято только 6 мегабайт, а не 60. Это из-за того что blob-объекты не содержат никакой информации об именах файлов, из которых они сделаны, поэтому они идентичны.

Вот пример создания blob-объекта:

$ mkdir ~/tmp/gitguts
$ cd ~/tmp/gitguts
$ git-init
Initialized empty Git repository in .git/

$ echo "Hello, World\!" > tutorial.txt
$ git-hash-object -w tutorial.txt 
8ab686eafeb1f44702738c8b0f24f2567c36da6d

$ find .git/objects -type f
.git/objects/8a/b686eafeb1f44702738c8b0f24f2567c36da6d

Как видно, вызов git-hash-object с параметром -w действительно создал и сохранил в базе новый объект типа blob, содержащий строчку "Hello, world!"

Посмотреть, что внутри объекта-blob можно с помощью команды git-cat-file

$ git-cat-file blob 8ab686eafeb1f44702738c8b0f24f2567c36da6d
Hello, World!

Этот новосозданный объект пролежит в базе до тех пор, пока не будет вызван "уборщик мусора" (git-prune или git-gc --prune). Этот трудяга проверяет "прописку" всех объектов, и если на объект не имеется никаких ссылок, то он удаляется из базы. На этот объект мы еще не сделали никаких ссылок, так что при сборке мусора он просто исчезает из базы.

$ git-prune
$ find .git/objects -type f
.git/objects/info/packs

Сами объекты-blob не могут иметь никаких ссылок. Вместо этого, на них ссылается другой объект - дерево(tree). О них мы поговорим в следующий раз.

Продолжение следует. Stay tuned!

Git Guts (part 1)

Mon, 13 Aug 2007 13:30:14 GMT

Где-то около месяца назад я полностью прочитал man git, и немножко поэкспериментировал с внутренностями git, чтобы понять, как же там все устроено внутри.

Оказалось, внутренне все сделано просто и элегантно.

В отличие от сложно-бинарных репозиториев subversion или недорепозиториев CVS, в git все кристалльно просто, и доступно даже на самом низком уровне.

Репозиторий git - это просто коллекция т.н. объектов, объединенных ссылками друг на друга. Каждый объект - это некий файл специального формата. У каждого объекта есть "имя", которое вычисляется как SHA1 хеш содержимого объекта и записываемся как шестнадцатеричное представление этого хеша. Длина хеша равна 20 байтам, так что шестнадцатеричное представление содержит 40 букв и цифр.

Для тех, кто не знает что такое хеш и зачем он нужен - поясняю буквально на пальцах.

Давайте отвлечемся от компьютеров и посмотрим на современную криминалистику. Как известно, преступники часто оставляют на месте преступления свои отпечатки пальцев. Эти отпечатки пальцев представляют собой комбинацию углов, завитков, спиралей и т.д. Эксперт, имея схему отпечатков, может просмотреть картотеку накопленных полицией/милицией отпечатков пальцев преступников, и найти совпадение. Существенное в этом методе то, что по минимальной информации - отпечаткам пальцев, удается (или не удается) найти преступника среди миллионов остальных людей.

У отпечатков пальцев есть три интересных свойства, которые и помогают провести опознание. Первое - что у одного и того же человека отпечатки пальцев в течение жизни практически не меняются. Второе - у разных людей
отпечатки пальцев разные (даже у неразличимых близнецов). Третье - их очень легко получить и найти - нужно всего лишь чернила и бумагу.

Вернемся к нашим баранам. Хеш-функция - это своеобразный "отпечаток пальца" файла и обладает всеми вышеперечисленными свойствами:
1. Если содержимое двух файлов совпадает - то их хеши тоже совпадают.
2. Если содержимое двух файлов различны - то их хеши тоже различны (за исключением случаев коллизий, о которых я расскажу ниже).
3. Вычислить хеш-функцию SHA1 можно очень быстро (фактически, современный процессор при этом не нагружается, узкое место тут - чтение файла с диска).

Возможны случаи, когда у двух разных файлов хеш-функция одинаковая.
Такие случаи называются коллизиями. Количество коллизий у любой хеш-функции бесконечно - ведь она позволяет любое количество информации преобразовать в фиксированное, конечное количество байт. Если бы людей было бы бесконечное количество - то среди них бы тоже бы наблюдались коллизии по отпечаткам пальцев или по любым другим методам опознания.

Поэтому различные хеш-функции отличаются сложностью возникновения коллизий (или их целенаправленного подбора). Хеш-функция SHA1 считается достаточно сложной для подбора или случайного возникновения коллизии, так как пока неизвестно алгоритма подбора коллизии, кроме как методом перебора, а криптологические особенности алгоритма уменьшают вероятность случайного возникновения коллизий.

Кстати, вычислить эту сумму для прозвольного файла в системе может специальаная утилита sha1sum, входящая в coreutils.

Коллекция объектов git - это "картотека", куда заносятся все объекты. Они упорядочены по именам, которые являются также SHA1 отпечатками объектов. Это имя позволяет быстро и однозначно идентифицировать объект, а также проверить его целостность - если объект повредился, его хеш не совпадет с именем.

Расположены все объекты в каталоге .git/objects. Для того чтобы не сваливать все объекты в одну директорию, git отделяет первые два символа имени объекта и создает поддиректорию с таким именем в .git/objects.

Вот например, содержимое базы некоторого git-репозитория

.git/objects/a4/b7fce097055c3cbd6879db9625f9a3890cc409
.git/objects/8c/3c7fbcd903744b20fd7567a1fcefa99133b5bc
.git/objects/e9/65047ad7c57865823c7d992b1d046ea66edf78

То есть в ней хранятся три объекта:

1. a4b7fce097055c3cbd6879db9625f9a3890cc409
2. 8c3c7fbcd903744b20fd7567a1fcefa99133b5bc
3. e965047ad7c57865823c7d992b1d046ea66edf78

Сделано это для ускорения поиска объекта по его имени. Несложно догадаться, что такой нехитрый прием ускоряет поиск в 256 раз.

Добавлю напоследок, что объекты в git бывают четырех типов - blob, tree, commit и tag.

Продолжение следует. Если есть какие-то вопросы или комментарии - милости прошу.