3

Если залить репозиторий до 400МБ, а потом удалить часть и оставить до 50МБ. То общий размер репозитория будет всеравно 400МБ? Ну чтобы востановить снимок тех 350МБ их же надо где-то хранить.

Вопрос связан с ограничениями размера репозиториев в частности GitHub.

Саша Черных
  • 4,314
rikimaru2013
  • 2,653
  • а 400 мегабайт - это сорцы или общий размер папки? – KoVadim Jan 27 '16 at 12:53
  • @KoVadim получается есть разница? я только начинаю использовать гит после svn – rikimaru2013 Jan 27 '16 at 12:54
  • 1
    Посмотрите в сторону git squash – Kromster Jan 27 '16 at 12:54
  • естественно есть. Гит хранит локальную копию репозитория (в скрытой папке .git). И даже, если все сорцы удалить и закоммитить, то размер уменьшиться ровно на размер сорцов за вычетом некоторый внутренний структур гита (инфу о удалении нужно сохранить) – KoVadim Jan 27 '16 at 12:59

1 Answers1

5

Естественно, если данные можно восстановить, то значит где-то они лежат.

Гит хранит разницы между состояниями файловой системы. Так что в вашем примере будет примерно так:

+400мб   - залили файлы (не принимая в расчет сжимающиеся они или нет)
+0,001мб - залили инфо о том что файлов больше нет

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

Дух сообщества
  • 1
Kromster
  • 13,809
  • Гит хранит разницы между версиями, (c) а в книге написано категорически другое. Кому верить вам или книге разработчиков?) – rikimaru2013 Jan 27 '16 at 12:56
  • 2
    гит хранит "снимки файловой системы на каждый конкретный коммит". – KoVadim Jan 27 '16 at 13:00
  • @KoVadim Всегда считал, что git дает доступ к снимкам "файловой системы на каждый конкретный коммит", а как он их внутри хранит его личное дело, и хранение разниц - самый эффективный вариант. См. http://stackoverflow.com/questions/8198105 примечание к первому ответу. – Kromster Jan 27 '16 at 13:07
  • разница не самый эффектнивный вариант ( в некоторых случаях). Например, если файл "сильно переписали", то diff (разница) может быть больше файла. – KoVadim Jan 27 '16 at 13:23
  • @KoVadim Разницу можно считать по разному, например в этом случае - все строки в 1 были удалены, все строки во 2 добавлены, будет почти равнозначно замене файла. Оставим это в "деталях реализации" ) – Kromster Jan 27 '16 at 13:29
  • Верить надо официально документации https://git-scm.com/documentation и в ней написано как раз что гит в отличии от svn хранит не изменения, а полностью снимок фс – user453575457 Feb 01 '16 at 06:48
  • @Mira: Повторюсь, git дает доступ к снимкам "файловой системы на каждый конкретный коммит", а как он их внутри хранит его личное дело, и хранение разниц - самый эффективный вариант. Еще раз, это внутренняя организация хранения, и она никоим образом не подрывает идеологию гита хранить снимки, без информации о том как прошли изменения. Предлагаю вам проверить, залив в репозиторий файл 1мб, и пролить десять раз изменения по 1 байту. Посмотрите, станет ли репозиторий занимать 10мб. – Kromster Feb 01 '16 at 07:11
  • @Mira Как оказалось, по крайней мере TortoiseGit, достаточно глуп, и действительно сохраняет весь упакованый файл в котором прошли изменения. Таким образом залив в репо несколько 700кб txt, каждое изменение в 1 файле прибавляет репозиторию по 100кб. – Kromster Feb 01 '16 at 07:27
  • @KromStern Так это ж одно из основных отличий гита, его фишка . в частности раздел в документации так и называется "слепки вместо патчей" и там речь имено о хранении а не представлении данных( https://git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git ) – user453575457 Feb 01 '16 at 08:45
  • @Mira Тем не менее, хранятся разницы (на уровне файлов). Если изменился 1 файл, то ревизия содержит только его, а не весь слепок с остальными файлами/папками? Проверьте – Kromster Feb 01 '16 at 09:02
  • Если копнуть глубже, то храниться все так: измененные файлы сохраняются в каталоге .git, а потом создается файл "дерева", где указаны хеши этих измененных файлов и ссылка на родительское дерево. Как результат - не нужно хранить список "всех файлов". – KoVadim Feb 01 '16 at 09:20
  • Да можно не проверять :) это тоже в той же доке есть - что если файл не изменен - то хранится ссылка на предыдущий. Я все к тому что все написано в документации и ей стоит верить в первую очередь – user453575457 Feb 01 '16 at 09:21
  • "Доверяй, но проверяй" как говорится :) – Kromster Feb 01 '16 at 09:22
  • Вообще с этим интересная ситуация. То, как себя ведут некоторые команды, заставляют считать, что коммит по смыслу это набор изменений. При этом внутри он представляет собой полные состояния файлов поначалу, но впоследствии они разностно сжимаются в основу и изменения для неё. Подробнее. –  Feb 28 '18 at 09:51