У show-object есть флаг, чтобы показывать их в норм виде

Там текстовая информация хранится текстом, а бинарная — в бинарном виде, ну :)

Хмм, перепроверил. У меня 2 файла, оба текстовые. Оба этих блоба и коммит - бинарно представлены, а папка-дерево в котором они лежат в такой же кодировке (мозг видимо в первый просмотр отключился у меня) что и пятый, значит ты прав, это root.
А откуда начинает строиться граф?

Лучше всего почитай git book, главу про internals. Она короткая и по делу, и намного лучше меня всё объяснит.

Ок, спасибо.

Я вообще, чего копаться-то начал, может граждане подскажут. У меня есть сущности, описанные в JSON файлах. Хранятся в MongoDB. Сейчас, когда пользователь грузит новую версию сущности, я вычисляю JSON Patch который надо применить к новой версии, что бы получить старую и сохраняю в базу новую версию файла, как основную сущность и ссылку на патч в виде предыдущей ревизии. Таким образом, над сущностью можно работать и откатиться в любой момент к нужной версии. Сейчас назрел вопрос, о создании чего-то вроде веток в гите, для одновременной работы нескольких людей над одной и той же сущностью. По факту, это легко делается путём введения указателей друг на друга. Дальше планируется введение чего-то похожего на merge. Но проблема в том, что сущности должны быть изменены семантически. То есть, взять условный libgit2 и втулить его у себя не получится. Соответственно я разбираюсь как гит устроен в надежде что это наведёт меня на мысли о том, как всё это реализовать. Возможно тоже придётся строить граф по внутренним сущностям и считать хэши для них. То есть, такой себе квази-гит, где вместо файлов и папок есть внутрянка JSON. Соответственно вопрос, может общая канва сумасшествия описываемого мной кому-то из присутствующих тут знакома? Что-то уже готовое или хотя бы в виде теоретических наработок.

Блин, пора отдохнуть... Не правильно всё написал:
Файл А - бинарный object;
Файл Б - бинарный object;
Подпапка с файлами А и Б - object в непонятной кодировке;
Коммит - object в непонятной кодировке;
5-ый object бинарный.

Если это root, то он же как tree в графе должен быть, так ведь? Почему он не в странной кодировке, а в бинарном виде, как остальные blob?

Если его просто из хекса в аски перевести, то ничего мне знакомого не видно...

Вообще все объекты пожаты deflate алгоритмом, поэтому выглядят вот так.

Почитай git book, ну :(

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects вот эту главу

И смотри на объекты через git cat-file -p <object_id>

Он сразу их разожмёт, и покажет читаемое представление для деревьев.

Ну и таки да, описанная схема выглядит разумно. Даже для самодельной VCS-like штуковины.

Спасибо, сейчас почитаю.

А с SVN кому-нибудь приходилось сталкиваться? Какие у нее есть недостатки по сравнению с гитом?

SVN — централизованная VCS, и поэтому многие операции (типа мержа, например) требуют в общем случае сетевого IO, и зачастую очень большого количества запросов (по HTTP-запросу на каждый файл в худшем случае, например), и поэтому выполняются очень медленно.

У меня на прошлой работе были проекты в SVN, и мерж пары веток мог занимать полчаса, к примеру. Просто вот от момента ввода команды svn merge и до того, как я смогу дальше работать (резолвить конфликты, к примеру) проходило полчаса.

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