Что имеет в виду Линус Торвальдс, когда говорит, что Git «никогда» не отслеживает файл?

В CVS история отслеживалась для каждого файла. Ветвь может состоять из различных файлов со своими различными ревизиями, каждая со своим номером версии. CVS был основан на RCS (Система контроля версий), который аналогичным образом отслеживал отдельные файлы.

С другой стороны, Git делает снимки состояния всего проекта. Файлы не отслеживаются и не управляются независимо друг от друга; ревизия в репозитории относится к состоянию всего проекта, а не одного файла.

Когда Git ссылается на отслеживание файла, это просто означает, что он должен быть включен в историю проекта. Выступление Линуса не касалось отслеживания файлов в контексте Git, а противопоставляло модели CVS и RCS модели на основе моментальных снимков, используемой в Git.

Я согласен с Брайан М. ответ Карлсона: Линус действительно проводит различие, по крайней мере частично, между системами контроля версий, ориентированными на файлы, и системами, ориентированными на коммит. Но я думаю, что это нечто большее.

В моя книга, который застопорился и может никогда не закончиться, я попытался придумать таксономия для систем контроля версий. В моей таксономии термин для того, что нас здесь интересует, — это атомарность системы контроля версий. Посмотрите, что сейчас на стр. 22. Когда система контроля версий имеет атомарность на уровне файлов, фактически для каждого файла существует история. Система контроля версий должна помнить имя файла и то, что происходило с ним в каждой точке.

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

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

Когда вы просите Git показать вам историю файла, используя:

git log [--follow] [starting-point] [--] path/to/file

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

• коммит является коммитом без слияния, и
• у родителя этого коммита также есть файл, но содержимое родителя отличается, или у родителя коммита вообще нет файла

(но некоторые из этих условий можно изменить с помощью дополнительных параметров git log, и есть очень сложный для описания побочный эффект под названием «Упрощение истории», который заставляет Git полностью исключить некоторые коммиты из обхода истории). История файла, которую вы видите здесь, в каком-то смысле не существует в репозитории: вместо этого это просто синтетическое подмножество реальной истории. Вы получите другую «историю файлов», если будете использовать другие параметры git log!

Git не отслеживает файл напрямую, а отслеживает снимки репозитория, и эти снимки состоят из файлов.

Вот способ взглянуть на это.

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

В Git нет прямой команды для этого. См. этот вопрос. Вы будете удивлены тем, сколько существует разных ответов. Нет простого ответа, потому что Git не просто отслеживает файл, а не так, как это делают SVN или ClearCase.

«git не отслеживает файлы» в основном означает, что коммиты git состоят из моментального снимка файлового дерева, соединяющего путь в дереве с «блобом», и графа коммитов, отслеживающего историю совершает. Все остальное восстанавливается на лету с помощью таких команд, как «git log» и «git fault». Эта реконструкция может быть указана с помощью различных опций, насколько тяжело она должна выглядеть для изменений на основе файлов. Эвристика по умолчанию может определить, когда большой двоичный объект меняет свое место в дереве файлов без изменений или когда файл связан с другим большим двоичным объектом, чем раньше. Механизмы сжатия, которые использует Git, совершенно не заботятся о границах больших двоичных объектов/файлов. Если содержимое уже находится где-то, это позволит сохранить небольшой рост репозитория без связывания различных больших двоичных объектов.

Теперь это репозиторий. Git также имеет рабочее дерево, и в этом рабочем дереве есть отслеживаемые и неотслеживаемые файлы. В индекс записываются только отслеживаемые файлы (область подготовки? Кэш?), и только то, что там отслеживается, попадает в репозиторий.

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

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

Это отличается от таких систем, как Subversion, в которых история записывать, а не реконструировать. Если этого нет в записи, вы не услышите об этом.

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

Запутанный бит здесь:

Git never ever sees those as individual files. Git thinks everything as the full content.

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

Но 160-битный хэш однозначно идентифицирует содержимое (в рамках базы данных git). Итак, дерево с хешами в качестве содержимого включает в себя содержание в своем состоянии.

Если вы измените состояние содержимого файла, его хэш изменится. Но если его хэш изменится, хеш, связанный с содержимым имени файла, также изменится. Что, в свою очередь, изменяет хэш «дерева каталогов».

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

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

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

Это может помочь думать о хэшах git как об указателе с подсчетом ссылок на неизменяемые данные.

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

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

Каждый раз, когда вы меняете один объект, он порождает новый документ. Старый документ продолжает существовать. Новый и старый документ имеют большую часть общего содержимого — у них одни и те же страницы (кроме 1). Эта страница имеет те же слои (кроме 1). Этот слой имеет те же группы (кроме 1). В этой группе те же объекты (кроме 1).

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

Репозиторий git очень похож на этот.

Это означает, что данный набор изменений git содержит свое сообщение фиксации (в виде хэш-кода), свое рабочее дерево и родительские изменения.

Эти родительские изменения содержат свои родительские изменения до самого конца.

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

Чтобы узнать, что происходит с файлом, вы начинаете с этого файла в наборе изменений. У этого набора изменений есть история. Часто в этой истории существует файл с таким же именем, иногда с тем же содержимым. Если содержимое такое же, в файле не было изменений. Если оно отличается, то есть изменение, и необходимо проделать работу, чтобы выяснить, что именно.

Иногда файл отсутствует; но дерево «каталогов» может иметь другой файл с тем же содержимым (тот же хеш-код), поэтому мы можем отслеживать его таким образом (обратите внимание: именно поэтому вы хотите, чтобы фиксация для перемещения файла была отделена от фиксации для перемещения). -редактировать). Или такое же имя файла, и после проверки файл достаточно похож.

Таким образом, git может объединить «историю файлов».

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

Кстати, отслеживание «контента» привело к тому, что пустые каталоги не отслеживались. Вот почему, если вы git rm последний файл папки, сама папка удаляется.

Так было не всегда, и только Git 1.4 (май 2006 г.) применил эту политику «отслеживания контента» с помощью совершить 443f833:

git status: skip empty directories, and add -u to show all untracked files

By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output).
Showing empty directories do not make sense, so pass --no-empty-directory when we do so.

Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files.

Спустя годы, в январе 2011 года, это повторилось в совершить 8fe533, Git v1.7.4:

This is in keeping with the general UI philosophy: git tracks content, not empty directories.

Между тем, с Git 1.4.3 (сентябрь 2006 г.) Git начинает ограничивать неотслеживаемый контент непустыми папками с зафиксировать 2074cb0:

it should not list the contents of completely untracked directories, but only the name of that directory (plus a trailing '/').

Отслеживание контента — это то, что позволило git fault на очень раннем этапе (Git 1.4.4, октябрь 2006 г., совершить cee7f24) быть более производительным:

More importantly, its internal structure is designed to support content movement (aka cut-and-paste) more easily by allowing more than one paths to be taken from the same commit.

Это (отслеживание контента) также является тем, что добавило git add в Git API с Git 1.5.0 (декабрь 2006 г., зафиксировать 366bfcb)

make 'git add' a first class user friendly interface to the index

This brings the power of the index up front using a proper mental model without talking about the index at all.
See for example how all the technical discussion has been evacuated from the git-add man page.

Any content to be committed must be added together.
Whether that content comes from new files or modified files doesn't matter.
You just need to "add" it, either with git-add, or by providing git-commit with -a (for already known files only of course).

Именно это сделало возможным git add --interactive с тем же Git 1.5.0 (зафиксировать 5cde71d)

After making the selection, answer with an empty line to stage the contents of working tree files for selected paths in the index.

Вот почему, чтобы рекурсивно удалить все содержимое из каталога, вам нужно передать параметр -r, а не только имя каталога в качестве <path> (все еще Git 1.5.0, зафиксировать 9f95069).

Просмотр содержимого файла вместо самого файла — это то, что позволяет использовать сценарий слияния, подобный описанному в зафиксировать 1de70db (Git v2.18.0-rc0, апрель 2018 г.).

Consider the following merge with a rename/add conflict:

• side A: modify foo, add unrelated bar
• side B: rename foo->bar (but don't modify the mode or contents)

In this case, the three-way merge of original foo, A's foo, and B's bar will result in a desired pathname of bar with the same mode/contents that A had for foo.
Thus, A had the right mode and contents for the file, and it had the right pathname present (namely, bar).

Совершить 37b65ce, Git v2.21.0-rc0, декабрь 2018 г., недавно улучшено разрешение конфликтов.
А совершить bbafc9c еще раз иллюстрирует важность рассмотрения файла содержание, улучшая обработку конфликтов переименования/переименования (2to1):

• Instead of storing files at collide_path~HEAD and collide_path~MERGE, the files are two-way merged and recorded at collide_path.
• Instead of recording the version of the renamed file that existed on the renamed side in the index (thus ignoring any changes that were made to the file on the side of history without the rename), we do a three-way content merge on the renamed path, then store that at either stage 2 or stage 3.
• Note that since the content merge for each rename may have conflicts, and then we have to merge the two renamed files, we can end up with nested conflict markers.