Чем опасен rebase, или как получилось, что 2*3=5

Однажды старший программист Антон искал причину очередного бага в очень важном проекте компании:

git bisect start
git bisect bad
git bisect good
…

В компании использовали rebase, история коммитов была линейной, и поиск по ней доставлял Антону одно удовольствие.
— Ага, нашел. Ну конечно: в коде написано «2*3=5», ещё бы оно работало с этим бредом! Какой @#$%^ это написал?


Антон: — Эй, Василий! Ты о чем думал, когда «2*3=5» писал?
Вася: — Да не было такого. Я «2+3=5» написал, точно помню.
Антон: — Это ты в сообщении к коммиту «2+3» написал, а в коде «2*3», вот смотри.

Вася посмотрел на свой коммит, и не верил своим глазам: действительно, в коде «2*3=5». В глазах у Васи потемнело…
Антон: — Эх, нельзя так безответственно, Василий, это неприемлемо.
Васю пришлось уволить…

В это время в параллельной реальности..

Антон ищет причину очередного бага в очень важном проекте. В компании используют merge, а не rebase, история коммитов нелинейна, поэтому Антон хмурит брови и периодически матерится, глядя на паутину слитых веток. Но git bisect умеет работать с нелинейной историей и его она ничуть не смущает.
— Ага, нашел. В коде «2*3=5», ещё бы оно работало. Так, это появилось, когда слили 2 ветки. В одной Вася складывает «2+3=5», всё верно написал, у нас и по ТЗ результат операции 5 должен быть. А в другой Петя умножает «2*2=4». Ага, а при слиянии получилось «2*3=5», понятно.

Антон: — Эй, Пётр! Ты зачем сложение на произведение заменил?
Петя: — Ну, мне показалось это более наглядным.
Антон: — Откати ка обратно, у нас из-за этого баг вылез.
Петя: — ОК.

Мораль: rebase меняет контекст, в котором были написаны коммиты, и теряет информацию о слияниях веток, которая может оказаться полезной для определения причины ошибки. Помните об этом.

Пример проекта на github.

Upd.
Если захотите воспроизвести, обратите внимание, что в проекте специально используется формат, несколько отличающийся от «2+2=4 (в столбик)», чтобы и merge и rebase прошли без конфликтов.