Направление стрелки в книге ProGit - PullRequest
5 голосов
/ 20 апреля 2010

Почему на всех изображениях, показывающих очередь коммитов в Pro Git book стрелки ведут в противоположное направление?

Ответы [ 2 ]

11 голосов
/ 20 апреля 2010

Стрелками указано направление, за которым следует DAG, Направленный ациклический график , представляющий здесь историю коммитов в Git (от самых последних до самых старых).

Это представление не является «идеальным», как подробности Эрика Синка в своей статье :

Одна из самых крутых вещей в инструментах контроля версий на основе DAG заключается в том, что DAGвыражение истории слияния.Мы интерпретируем стрелки в DAG, чтобы они означали: «У меня есть это».

alt text

Итак, когда приходит время объединяться с 5b зав ветке (a) мы можем использовать информацию в DAG, чтобы узнать, что 3b и 2b уже выполнены


В той же статье подробно описан предел этого представления:

Cherrypicking

Но DAG - это всего лишь одна реализация истории слияний, и она определенно не идеальна.

Стрелка в DAG контроля версий переходит от дочернего к родительскому.Он говорит нам, что ребенок содержит все изменения в родительском .И его бабушка и дедушка.И его прадедушка.И так далее.

Но что, если это не так?

Рассмотрим следующую картину:

alt text

Я хочу создать набор изменений 4.
Я хочу начать с набора изменений 1, а затем я хочу применить изменения из набора изменений 3, но НЕ вещи из набора изменений 2.
Эта операция иногда называется "cherrypicking",Я не хочу объединять все изменения из одной ветви в другую.Я просто хочу взять один набор изменений (или одну часть набора изменений) и применить его как патч к другому месту.

Как мне представить это в DAG?

Я могу 'т.

  • Я мог нарисовать стрелку от 4 до 3 (показано выше красным).Это будет правильно сказать, что 4 содержит изменения в 3, но это будет НЕПРАВИЛЬНО утверждать, что 4 содержит изменения в 2.
  • ИЛИ, я не мог нарисовать стрелку.По сути, моя история слияний просто не будет отражать тот факт, что 4 - это действительно 3, преобразованные в патч и примененные к 1.

В любом случае в следующий раз произойдет что-то плохоеобъединить одну ветвь с другой:

  • Если я нарисую лежащую стрелку, у меня не будет возможности применить набор изменений 2, поскольку история объединения считает, что я это уже сделал.
  • Если я не нарисую стрелку, инструмент будет ожидать, что я буду иметь дело с набором изменений 3, поскольку в истории слияний нет записи о том, что я уже это сделал.

Ни одна из этих проблемЭто достаточно катастрофично, чтобы делать вечерние новости, но все же.

Вот почему перебазировка никогда не бывает далека после операции выбора вишни, чтобы вернуться к более классическойDAG.

6 голосов
/ 20 апреля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...