Просто добавьте к siri 's ответ , "число генерации коммитов":
Генерация коммита - это его высота в графе истории, как
измеряется от самого дальнего корня . Он определяется как:
- Если у коммита нет родителей, его генерация равна 0.
- В противном случае его поколение на 1 больше, чем максимальное число его родительских поколений.
- старая тема, уже упоминавшаяся при создании Git в 2005 году:
Линус Торвальд (вчера, 14 июля):
Итак, я вижу, что старая дискуссия о номерах поколений всплыла на поверхность.
И я должен сказать, что с шестью годами использования мерзавцев, я думаю, это не совпадение, что понятие чисел поколений встречалось несколько раз за эти годы: я думаю, что их отсутствие является буквально единственной реальной ошибкой дизайна, которую мы имеем.
[...]
На самом деле он появился еще в июле 2005 года, поэтому «давайте использовать номера поколений в коммитах» - это действительно старый.
- о вопросе быстрого знания, является ли коммит предком другого коммита (без необходимости возвращаться к DAG - графу коммитов):
Я думаю, что вполне разумно сказать, что проблема в основном сводится к одному git-вопросу: «может ли коммит X быть предком коммита Y» (как способ в основном ограничить определенные алгоритмы от необходимости проходить весь путь вниз) , Мы использовали для этого даты фиксации, и реально это действительно сработало очень хорошо. Но это всегда была нарушенная эвристика.
Так что да, я лично вижу счетчики поколений как способ правильного сравнения дат фиксации. И было бы прекрасно просто сказать: «если нет номеров поколений, мы вместо этого будем использовать метки даты и знать, что они могут быть неправильными».
То, что откат "использовать метки даты" вполне может включать в себя всю эвристику, которую мы уже выполняем (т.е. проверяем, выглядят ли марки в здравом уме, а не доверяют только одной отдельной).
Как упоминается в новостной ленте Hacker:
Номера поколений являются результатом состояния дерева, в то время как временные метки выводятся из окружающей (и потенциально неверной!) Среды, из которой была сделана фиксация.
В настоящий момент каждый коммит хранит ссылку на родительское дерево .
Разобрав это дерево и прочитав всю историю , вы можете получить иерархию коммитов.
Поскольку вам нужно упорядочивать коммиты во многих ситуациях, чтение всей истории крайне неэффективно, поэтому git использует временные метки для определения порядка коммитов.
Это, конечно, не работает, если системные часы на данном компьютере выключены.
С номером поколения вы можете получить заказ локально из последних коммитов, не полагаясь на временные метки или читая все дерево .
Когда у вас есть коммит с поколением n, любые последующие коммиты, которые включают его, будут иметь поколение >n, поэтому, чтобы определить соотношение между коммитами, вам нужно только взглянуть назад n, и вы можете немедленно получить порядок любых промежуточных коммитов.
Это не имеет ничего общего с «легко запомнить». Это делает git более эффективным и надежным
Номера поколений полностью избыточны с фактической структурой истории, представленной родительскими указателями.
Linus:
Не верно. Это верно только в том случае, если вы добавите «... если вы проанализируете всю историю» в этом утверждении.
И мы никогда не анализировали всю историю, потому что это слишком дорого и не масштабируется . Так что сейчас мы зависим от дат коммитов с несколькими взломами.
Так что нет, номера поколений совсем не избыточны.Они фундаментальные.Вот почему мы обсуждали это шесть лет назад.
До сих пор ведутся споры о том, где кэшировать эту информацию (или ее следует кэшировать), но с точки зрения пользователя., это все еще о некоторой «легко запоминающейся» информации (которая не является целью числа генерации коммитов):
Так что это почти, но не совсем, как и номера ревизий для всехеще всегда было?
Да - почти, но не совсем.
Если вы и я каждый создадим ветку коммитов с gen #123, то, насколько я понимаю,последующие коммиты в моей ветке будут #124, #125 и т. д., и ваши коммиты в вашей ветке также будут #124, #125 и т. д.
Сравните это: - сCVS, где у меня будет 1.124.1.1, 1.124.1.2 и т. Д., А у вас будет 1.124.2.1, 1.124.2.2 или - с Subversion, где я могу получить ревизии 125, 128 и 129, в то время как сервер дал ваши коммиты #124, 127 и 130, а также кому-то еще, в совершенно другой частипроект получил #126.
Пока разработка идет линейно, в одной ветке, тогда да, речь идет о сохранении номеров ревизий в централизованном RCS - хотя, как только вы начнете ветвиться и объединяться,он полностью представляет другую концепцию.
Для одного репозитория он имеет очень похожую интерпретацию, скажем, svn revnos.
Вы можете говорить о "ревизии # 125 ветки" в конкретномрепозиторий.Как правило, это именно то, что вам нужно для общения между людьми о разработке.
"Вы видите, является ли эта ошибка нестабильной в r125?"«У меня есть все изменения до r245 продукта»
Я думаю, что сбивающий с толку аспект был бы, если бы «r245 of prod» на центральном сервере был «r100 продукта» в моем локальном репо, потому что я не клонировалполная история?