How do git grafts and replace differ? (Are grafts now deprecated?)

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 superseded git 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

Leave a Comment