Никто из здешних не сможет объяснить суть явления? Или хотя бы задать вектор для самостоятельного копания... хотя, второе не столь важно.

Kalter, что-то последний абзац совсем сложный. reword второго коммита с HEAD или с начала истории?
Вероятно, ты не сможешь смерджить. Будет несоответствие истории, а значит и merge не произойдёт.

Однако, смог. Имена коммитов остались неизменёнными (в ветке, куда мерджили другую с изменённой историей).

Цитата aNNiMON:

---

reword второго коммита с HEAD или с начала истории?Вообще, имелось ввиду второго после root, но это не столь важно.

Kalter, в принципе логично, учитывая, что файлы остаются одними и теми же.
Если интересно, можешь прочитать про merge-стратегии, там их довольно много.

git 2.7 релизнулся. Из главного: git bisect теперь работает с old / new, вместо good / bad. Эти термы можно переопределить:
Ещё говорят, что объединили опции для git branch, git tag и git for-each-ref. Всё остальное Atlassian разъясняют в своём блоге, рекомендую посмотреть.

Ксакеп, чо за бисект?

Oak, это когда ты хочешь найти баг в истории проекта с помощью бинарного поиска по коммитам в истории.

Ксакеп, а как с помощью поиска найти баг в истории проекта?

Oak, предполагается, что существует ревизия X, в которой появляется определённый баг. Соответственно предыдущая ревизия X^ не содержит этого бага, а все последующие — содержат. Условно, это можно обозначить набором чисел (0...000111...1), где первая единица — это ревизия X; единицы свидетельствуют о наличии бага, нули — об отсутствии.

Очевидно, применим алгоритм бинарного поиска. Git делает checkout на некоторый коммит, разработчик смотрит проект, и отмечает ревизию как good или как bad в случае наличия бага. Процедура повторяется, пока не будет найден коммит X.

Оффтоп и бан мне, но ребят, вы доставляете, умеете, могёте.