GIT или Mercurial — история задним числом. Возможно ли?

А архивы меняются? Если нет, то можно просто и вести историю наоборот: самый первый коммит — самая последняя версия. )

Не совсем понял, оно или нет:
http://stackoverflow.com/questions/645450/git-how-to-insert-a-commit-as-the-f...

Надо будет попробовать.

https://git.wiki.kernel.org/index.php/GraftPoint

Оно, но rebase долгий, не сохраняет слияния (rebase -p должно помочь) и возможны конфликты при первом коммите (rebase -s theirs должно помочь).

можно просто и вести историю наоборот: самый первый коммит — самая последняя версия. )

Увы, _штатное_ использование — именно прямая история :) Просто фишка в том, что в десятке мест раскиданы сотни бэкапов за 14 лет работы. И хочется из всего этого восстановить связную историю изменений :) Но проблема в том, что нельзя гарантировать, что я найду сразу все старые бэкапы. Так что в какой-то момент гарантированно попадётся что-то из более старого. И надо будет это всё вписывать в более раннее состояние. Равно, как могут попадаться и промежуточные срезы, которые надо будет вставлять в середину.

А старые изменения планируется добавлять поштучно (коммит за раз) или пачками? Если второе, то grafts лучше, вроде как.

А старые изменения планируется добавлять поштучно (коммит за раз) или пачками?

Ну, логика такая. Есть текущий репозиторий в обычном виде, хранящий архив в виде .json сообщений. Часть из них когда-то ранее менялась.

Находится в заначке древний mysqldump. Я его преобразую в набор json — некий срез БД за старую дату на момент бекапа. И нужно «вставить» этот набор в текущий репозиторий как если бы он сколько-то времени тому назад был в таком виде.

Ага, то есть один бэкап — один коммит. Тогда rebase, да.