git-поддерево без сквоша: просмотр журнала

Я объединил дерево с моим репозиторием, используя поддерево git add без опции squash. Журнал git показывает, что коммиты были успешно добавлены в репозиторий. Однако, если я делаю git log --follow filename, история останавливается на слиянии и не показывает предыдущие коммиты. Я попробовал использовать -M вместо --follow, и это тоже не работает. Как я могу получить журнал фиксаций для определенного файла или файлов до слияния?

2 12
git-subtree

2 ответа:

На самом деле, git log --follow следует работать со слияниями поддеревьев, но это, как известно, уже давно хакиш [1-3].

Можно придерживаться слияния поддеревьев и оставаться уверенным, что стратегия верна для отслеживания нескольких историй, и терпеливо ждать неизбежного события, которое git log --follow улучшится. Это действительно может быть жизнеспособным решением, поскольку в настоящее время git log --follow может видеть некоторую историю в очень полезных случаях. Допустим, вы переместили файл из РЕПО верхнего уровня в субрепо, а затем он может отслеживать полный ход. Если вы хотите отслеживать историю, специфичную для субрепо, вам действительно нужно иметь отдельную копию или проверить филиал субрепо.

Альтернативы и обходные пути

Вы можете получить журналы для таких файлов, как [1]: 

git log -- '*filename'          # from the toplevel

Это просмотр каждого коммита, который коснулся файла, имя которого заканчивается на filename. Он не будет следовать фактическим переименованиям и может показать ложь положительно, если у вас есть несколько файлов с одинаковым базовым именем [1].

Вы также можете объединить репозитории используют разные стратегии. Ref [4] показывает способ сделать это, который очень близок к тому, что вы имеете при регулярном слиянии поддеревьев, но с отслеживаемыми историями. В основном, вы:

  1. добавьте, извлеките и объедините каждый суб-репозиторий с репозиторием верхнего уровня как обычное удаленное поддерево без Git или readtree. Во-первых, это будет загрязнять ваш корневой dir, как если бы он был их, так что это должно быть сделано в начале жизни проекта.
  2. git mv файлы субрепо для разделения папки

Затем:

  • восходящие изменения могут быть извлечены и объединены нормально, но с флагом -Xsubtree для слияния git.
  • другие случаи должны быть аналогичными. Я протестировал pushing upstream, и это работает, см. комментарий в [4].

Ссылки

[1] из списка рассылки git http://git.661346.n2.nabble.com/Bug-Files-are-losing-history-after-subtree-merge-td7597197.html

[2] из рассылки git список http://git.661346.n2.nabble.com/gsoc-Better-git-log-follow-support-td6188083.html#a6188352

[3] git log --follow был в Google летом кода https://git.wiki.kernel.org/index.php/SoC2011Ideas#Better_git_log_--follow_support

[4] https://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history

4

Фиксация, созданная git subtree merge или git subtree add, выполняет "добавление" для файлов, поступающих из поддерева, а не "перемещение". Это означает, что их история не может быть прослежена, как в случае с другими слияниями или движениями.

История для нужного файла все еще может быть отображена путем просмотра непосредственно в поддереве перед слиянием. Если ваша рабочая область является коммитом слияния, созданным git subtree, то второй родительский элемент (HEAD^2) будет последним коммитом исходного поддерева. Отсюда вы можете видеть содержимое исходное поддерево: 

# Display the contents of the original subtree
git ls-tree HEAD^2

С помощью этого коммита вы можете отслеживать изменения интересующего вас файла. Будьте осторожны, чтобы путь к вашему файлу был другим в поддереве, которое находится в вашем рабочем пространстве. Вам нужно будет удалить --prefix, данное git subtree, чтобы иметь правильный путь для вашего файла.

git log HEAD^2 --follow -- path-in-subtree/file
14