Как Git коммитит (обновляет) бинарные файлы?

Он смотрит на фазы спутников юпитера, и в зависимости от величины тени на Ганимеде обновляет файл.

Он смотрит на фазы спутников юпитера, и в зависимости от величины тени на Ганимеде обновляет файл.

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

Да, у меня складывается такое впечатление.

Перекрестись. Поведение ничем не отличается от «небинарных» файлов.

Git в репозитории хранит все версии всех файлов. Различие между бинарными и небинарными проявляется только при выводе diff и при мерже.

Поведение ничем не отличается от «небинарных» файлов.

Да ладно. Если Вася изменил что-то в одном месте текстового файла, а Петя в другом месте того же файла, Git может на автопилоте получить «обобщенный» файл. Для бинарных файлов это не так.

Разве к месту. А ежели ваши Вася с Петей поменяют один и тот же участок кода?

Обычно единица отслеживаемых изменений - строка. Бинарный можно считать цельной строкой.

Да ладно. Если Вася изменил что-то в одном месте текстового файла, а Петя в другом месте того же файла, Git может на автопилоте получить «обобщенный» файл. Для бинарных файлов это не так.

Хранит git таки целиком версии файлов. Каждая версия каждого файла - отдельный обьект со своим sha хешем, набор файлов с датами, и прочими аттрибутами - другой обьект, со своим sha хешем, который есть коммит.

«Обобщенный файл» гит получает анализируя изменения между параллельными коммитами, а не «склеивая два diff-а простым strcat».

В плане хранения бинарный файл не отличается от текстового. Отличия заключаются в поведении в случае конфликта.

Хорошо, тогда такой вопрос. Вот команды:

git add . ; git commit -a -m MyCommit ; git pull -s recursive ; git push

Будет ли при синхронизации текстовых файлов другой результат, если поментять местами pull и commit?

AFAIK Если поменять местами pull и commit, и возникли конфликты в не закоммиченных файлах, то гит просто не даст завершить pull, пока конфликтные файлы не будут либо закомиченны, либо содержимое вернется к прежнему значению.

В итоге, поменять их местами просто не удастся.

По какому принципу Git обновляет в репозитарии бинарные файлы (например, картинки)?

а погуглить? http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html http://book.git-scm.com/7_how_git_stores_objects.html http://book.git-scm.com/1_the_git_object_model.html

http://nfarina.com/post/9868516270/git-is-simpler — читать начиная с The So-Called “Object Database”

Последняя измененная и закоммиченная версия файла считается самой актуальной, и будет роздана другим пользователям при синхронизации?

Git хранит текстовые файлы и бинарные одинаково — как блобы, то есть просто контент файла. Блобы хранятся «по адресу», равному SHA1 хешу от содержимого блоба, то есть это Content-Addressable Memory (другое развитие этой идеи — в camlistore и gittorrent

Далее, блобы организованы в деревья блобов. Один тип деревьев — директории, другой — коммиты, третий — ветки. То есть, ветка — это снепшот файлов-блобов.

Последняя измененная и закоммиченная версия файла считается самой актуальной, и будет роздана другим пользователям при синхронизации?

а «последняя закомиченная версия» — это ссылка на блоб в дереве веток и коммитов.