git - git grafts 和 replace 有何不同？ (现在不赞成移植吗？)

Question

关于 git grafts 与 replace 的问答很少。搜索 [git] +grafts +replace 只找到两个与 5 相关的。what-are-git-info-grafts-for和 git-what-is-a-graftcommit-or-a-graft-id .关于 git.wiki.kernel.org:GraftPoint 也有注释

移植现在是否被 replace 和 filter-branch 完全取代，或者它们是否仍然需要一些特殊的极端情况(和落后的情况)兼容性)？

一般来说，它们有何不同(例如，它们在 repo 协议(protocol)之间传输)，以及它们在一般情况下有何相同之处？我已经看到 Linus 目前在关于提交世代数(最大父代回到任何根变体)的讨论中似乎并不关心嫁接 "Grafts are already unreliable."

编辑:找到更多信息。
在 www.kernel.org/pub/software/scm/git/docs 中搜索 graft 只找到 3 个结果:

1. git-filter-branch(1),
2. v1.5.4.7/git-filter-branch(1),
3. v1.5.0.7/git-svn(1).

发现范围稍广的搜索 RelNotes/1.6.5.txt其中包含:

• refs/replace/ hierarchy is designed to be usable as a replacement of the "grafts" mechanism, with the added advantage that it can be transferred across repositories.

不幸的是，gitrepository-layout(5)尚未更新 refs/replace/存储库布局信息(和注释)，也没有任何 info/grafts 的弃用注释。

这更接近于支持我的想法，但我欢迎任何确认或澄清。

Answer 1

在same discussion关于Commit Generation Number你提到的，Jakub Narębski does confirm移植问题多于解决方案:

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.

(发布一直由 git filter-branch 处理，如此 2008 thread on grafts workflow 所示。)

grafts之间的区别和 git replace最好用这个 SO question "Setting git parent pointer to a different parent" 来说明, 以及 (Jakub's again) answer 的评论.

它确实包括对 Git1.6.5 的引用

From what I understand (from GraftPoints), git replace has superseded git grafts (assuming you have git 1.6.5 or later)

(雅库布:)

• 如果你想重写历史然后grafts + git-filter-branch(或交互式rebase，或快速导出+例如reposurgeon ) 是这样做的方法。
• 如果您想要/需要保留历史，那么git-replace 远优于嫁接