In the same discussion about Commit Generation Number that you mention, Jakub Narębski does confirm that grafts are more aproblem than a solution:
grafts are so horrible hack that I would be not against turning off generation numbers if they are used.
In the case of replace objects you need both non-replaced and replaced
DAG generation numbers.
[…] Grafts are non-transferable, and if you use them to cull rather than add
history they are unsafe against garbage collection… I think.
(publishing has always been taken care of with git filter-branch
, as illustrated by this 2008 thread on grafts workflow.)
The difference between grafts and git replace is best illustrated by this SO question “Setting git parent pointer to a different parent”, and the comments of (Jakub’s again) answer.
It does include the reference to Git1.6.5
From what I understand (from GraftPoints),
git replace
has supersededgit grafts
(assuming you have git 1.6.5 or later)(Jakub:)
- if you want to rewrite history then
grafts
+git-filter-branch
(or interactive rebase, or fast-export + e.g. reposurgeon) is the way to do it.- If you want/need to preserve history, then
git-replace
is far superior to graft