Git -История файла, который был изменен поддеревом git merge -s - PullRequest
1 голос
/ 06 августа 2020

Как я могу получить git журнал, чтобы показать мне всю историю файла, когда даже git log -M --follow --full-history new/directory/file не удалось.

Но сначала немного контекста об изменениях, которые не отображаются ...

Мы импортировали репозиторий git в другой, мы поступили так:

git clone git@domain.com:namespace/NewRepository
cd NewRepository
git remote add oldRepository git@domain.com:oldNamespace/oldRepository.git
git fetch oldRepository
git checkout -b old-master oldRepository/master
mkdir -p new/directory/
git mv -k * new/directory/
find . -name ".*" -d 1 -exec git mv -k {} new/directory/ \;
git commit -m "Move oldRepository to its new location"
git push --set-upstream origin old-master
git checkout master
git pull
git merge old-master --allow-unrelated-histories
git push

Пока все хорошо, после этого git log --follow new/directory/file предоставит мне полный журнал изменений файла.

Примерно через неделю некоторые новые изменения в старом репозитории нужно было «перенести» в новый. Мы поступили так:

git fetch --all
git checkout old-master; 
git merge origin/old-master; # I got no conflict (No change actually)
git merge origin/master; # I got no conflict (As expected)

git merge -s subtree -X patience oldRepository/master; 
# I am not sure "-X patience" is a thing but that's what we ran.
# But the "-s subtree" is the important part I believe, we got no conflict and all expected changes were found in their new location (Even newly created files)

git push --set-upstream origin old-master

Затем я создал PR, а затем в конечном итоге слил его, используя параметр create a merge commit .

Теперь, если я это сделаю git log --follow new/directory/file последняя фиксация, которую я вижу: Move old repository to its new location, но я не получаю более новой записи из старого репозитория, которая была сделана после исходного импорта. Несмотря на наличие изменений в файле.

Однако:

  • A git blame new/directory/file показывает мне рядом с измененной строкой правильную информацию
  • A git log (Без указанного файла) показывает фиксацию
  • A show history в моей IDE показывает мне запись журнала.

Поскольку моя IDE делает это, я предполагаю есть комбинация флагов для журнала git, чтобы показать мне правильную историю, но я пробовал МНОГО комбинации и не мог понять. И да, я прочитал справочную страницу ...

Кроме того, если бы другая процедура могла помешать мне попасть в эту ситуацию, я хотел бы знать ... Доу, оглядываясь назад, возможно, old- master ветка была ненужной, но изначально казалось хорошей идеей иметь ветку для разрешения конфликта.

Спасибо!

1 Ответ

0 голосов
/ 07 августа 2020

Если фиксация слияния не внесла дополнительных изменений в целевой файл, git log new/directory/file не будет отображать саму фиксацию слияния (что может немного беспокоить), и в зависимости от порядка, в котором она выбирает отображение коммитов, коммиты из вашей old-master ветки может быть дальше по списку log.

Попробуйте добавить параметр --graph:

git log --graph --follow new/directory/file
# or
git log --graph --oneline --follow new/directory/file

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

Вы также можете попробовать флаги --date-order, --author-date-order и --topo-order.

[править], когда я впервые прочитал ваш вопрос, я почему-то подумал, что new/directory также был создан и помещен в oldRepository. Итак, я сделал вывод, что изменения в oldRepository были применены к new/directory/file, и я обнаружил, что удивительным, что git не перечисляет историю new/directory/file.

Теперь я понимаю, что в oldRepository , путь к файлу - /file, и включение новых коммитов как части git log --follow new/directory/file зависит от эвристики git для поиска переименований.

Что касается параметров в git log, пробовали ли вы:

  • с использованием -C и --find-copies-harder?
  • установка нижнего порога обнаружения с помощью -M? (по умолчанию 50%, например -M40%)?
  • , если окончания строки crlf должны были отличаться в двух репозиториях: --ignore-cr-at-eol?
  • параметры настройки игнорирования изменений пробелов: --ignore-whitespace-at-eol или -b?

Что касается «переименования» в git: вы, конечно, знаете, что git не отслеживает переименование в своей истории, он просто отслеживает контент, который вы указываете ему хранить . Когда он отображает «переименование» в git log или git status или ... он фактически пытается угадать, какие файлы могли быть переименованы, глядя на разницу между глобальным контентом. Параметр -M50%, например, говорит, что он будет считать, что file B был возможно «перемещен» из file A, если 50% файлов совпадают.

...