git 移植和替换有何不同?(现在不推荐移植吗?) [英] How do git grafts and replace differ? (Are grafts now deprecated?)

问题描述

关于 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取代，或者它们是否仍然需要用于一些特殊的极端情况(和落后的情况)?兼容性)?

一般来说，它们有何不同(例如，哪些在 repos 之间传输)，以及它们通常如何相同?我已经看到，在关于提交代数(最大父母回到任何根品种)的讨论中，Linus 目前似乎并不关心移植"移植已经不可靠了."

找到更多信息.
在 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/层次结构旨在用作替代的移植"机制，具有额外的优势，它可以跨存储库传输.

不幸的是，gitrepository-layout(5) 尚未与 refs/replace/存储库布局信息(和注释)保持同步，也没有任何信息/移植的弃用说明.

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

解决方案

在相同的讨论关于您提到的提交代号，Jakub Narębski 确实证实移植物比解决方案更麻烦:

<块引用>

移植是如此可怕的黑客，如果使用它们，我不反对关闭世代数.
在替换对象的情况下，您需要非替换和替换对象DAG 代数.
[...] 嫁接是不可转让的，如果您使用它们来剔除而不是添加历史，他们对垃圾收集不安全......我认为.

(发布一直由 git filter-branch，如这个 2008 年关于移植工作流程的线程所示.)

grafts 和 git replace 最好地说明了这个SO question "Setting git parent pointer to a different parent"，以及(Jakub 再次回答).

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

<块引用><块引用>

据我所知(来自 GraftPoints)，gitreplace 已经取代了 gitrafts(假设你有 git 1.6.5 或更高版本)

(雅各布:)

• 如果你想重写历史，那么grafts + git-filter-branch(或者交互式rebase，或者fast-export + eg reposurgeon) 是这样做的方法.
• 如果你想/需要保留历史，那么git-replace远远优于graft

There are very few Q&A's on git grafts versus replace. The search [git] +grafts +replace only found two that felt relevant of the 5. what-are-git-info-grafts-for and git-what-is-a-graftcommit-or-a-graft-id. There is also a note on git.wiki.kernel.org:GraftPoint

Are grafts now completely overtaken by the replace and filter-branch, or do they still needed for some special corner cases (and backward compatibility) ?

In general, how do they differ (e.g. which are transported between repos), and how are they generically the same? I've seen that Linus doesn't appear to care about grafts at present in the discussion on commit generation numbers (of the max parents back to any root variety) "Grafts are already unreliable."

EDIT: more info found.
A search of www.kernel.org/pub/software/scm/git/docs for graft only found 3 results:

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

A slightly broader search found RelNotes/1.6.5.txt which contains:

• 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.

Unfortunately, the gitrepository-layout(5) isn't yet up to date with the refs/replace/ repository layout info (and notes), nor any deprecation note of info/grafts.

This gets closer to supporting what I was thinking but I'd welcome any confirmation or clarification.

解决方案

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

这篇关于git 移植和替换有何不同?(现在不推荐移植吗?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！