Git Merge Пропуск коммита

Question

У меня есть ветвь, которую я слил в мастер.

В ветке git log file показывает коммит 9 февраля На мастере git log file не не показывает коммит 9 февраля На мастере git log показывает фиксацию 9 февраля

Файл не отражает изменения, сделанные 9 февраля, однако git log показывает фиксацию. Похоже, git слился с коммитом, но фактически не применил его к файлу. Что может быть причиной этого?

Редактировать: мне кажется, я понял, что произошло, и ответил ниже. Я очистил исходный вопрос для ясности. Первоначально я написал, что считаю это ошибкой в ​​git, но я не думаю, что это больше так. Однако было бы неплохо, если бы git log file показывал эти коммиты в файл. Спасибо всем, кто помог, особенно Бореалиду.

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

Answer 1

Цитируется из Дэйва:

Я воссоздал похожую ситуацию с помощью следующих шагов:

• Создать новый репозиторий git
• Создайте файл с одной строкой, добавьте его в git и commit (commit # 1)
• Создать и переключиться на ветку
• Изменить файл в ветке, commit (commit # 2)
• Переключиться на master, изменить файл, чтобы возник конфликт, и зафиксировать (commit # 3)
• Объединить ветку с мастером, файл будет конфликтовать
• Разрешите конфликт, приняв все изменения в мастере и отклонив все изменения в ветви. По сути, файл должен Посмотрите, как это было в мастере.
• Добавить файл и зафиксировать изменения (commit # 4)

Теперь в git log будут отображаться все четыре коммита, но в файле git log будут отображаться только коммиты # 1 и # 3

Резонанс, что git log -- file показывает только коммит # 1 и # 3, заключается в том, что git-log (режим по умолчанию) обходит цепочку коммитов; Когда коммит слияния найден и существует родительский коммит, такой что выбранный файл имеет то же содержимое после слияния, что и в родительском коммите, git-log будет следовать (одному) такому родителю и отвергнет всех остальных родителей.

В этом случае, поскольку конфликт слияния разрешается только сохранением изменений, внесенных в master (файл будет иметь одинаковое содержимое в commit # 1 и commit # 4), git-log будет обходить только ветку master.

Более детально: http://schacon.github.com/git/git-log.html (раздел «Упрощение истории»)

Answer 2

Я воссоздал похожую ситуацию с помощью следующих шагов:

1. Создать новый репозиторий git
2. Создайте файл с одной строкой, добавьте его в git и commit (commit # 1)
3. Создать и переключиться на ветку
4. Изменить файл в ветке, commit (commit # 2)
5. Переключиться на master, изменить файл, чтобы возник конфликт, и зафиксировать (commit # 3)
6. Объединить ветку в мастер, файл будет конфликтовать
7. Разрешите конфликт, приняв все изменения в мастере, и отклоняя все изменения в ветке. По сути, файл должен Посмотрите, как это было в мастере.
8. Добавить файл и зафиксировать изменения (commit # 4)

Теперь git log покажет все четыре коммита, но git log file покажет только коммиты # 1 и # 3.

Answer 3

Если содержимое файла идентично до и после изменения, файл не был изменен изменением.

Это утверждение интуитивно верно, и из-за объектной модели git оно верно в репозиторииа также.

Вы можете проверить свой git log и найти ревизию, которая, по вашему мнению, изменила файл;если он есть в основной истории, вы сделали слияние правильно, но этот набор изменений не оказал влияния на файл (и поэтому не включен в git log -- path/to/file).

Очевидно, git merge не нарушен -ваши ожидания просто не соответствуют тому, что он делает.