3

.patch我尝试（在一个小型测试存储库上）将存储库导出到使用命令为每次提交生成的一系列文件git format-patch中，然后通过在空目录上使用“git init”git apply以及每个补丁文件的命令来重构存储库。它起作用了——只有一个问题——当git am将补丁应用到存储库而不是保留补丁的 ID 标签时，它会生成一个新标签。这在以后可能会成为一个问题，因为它可能难以确定哪些提交是多余的，哪些不是。

至于为什么我不使用克隆存储库的常规方法，例如git clone- 答案是一般来说，我确实使用git clone克隆存储库 - 但我目前有非常具体的原因来尝试看看我是否可以这样做这种方式太长了，无法在这里详细介绍（尽管我可能会在这个问题后面提到原因）——不仅这些原因太长，而且我看不到它们的最终细节如何影响这个问题的正确答案是。

但是，如果您告诉我这.patch不是用于此目的的正确文件格式，我愿意接受。我想做的最重要的是：

  1. 提取对 repo 的单个提交到单个文件 - 并了解这些文件在 repo 历史记录中的顺序等。

  2. 能够根据提交的那些提取版本完全重构 repo

  3. 稍后能够“取消规范化”我认为不应该进行的任何提交（并且将其保存在存储库的历史记录中不值得它会导致项目历史记录大小膨胀），以便我可以在没有“去规范化”提交的情况下重新构建 repo。（顺便说一下，第 3 方面与我希望能够做到这一点的原因非常相关。）

4

1 回答 1

2

I am not 100% clear what you are asking here. I'm going to presume that when you say "commit ID-tag" you mean SHA. And I don't know at all what you mean by "patch ID-tag".

So guessing ...

When you create a commit in git it has 6 pieces of meta-data attached to it. Those are Author Name/Email/Time and Committer Name/Email/Time. If you are creating a new commit from scratch the author name/email and committer name/email will both match.

They don't have to do. You can override them via GIT_AUTHOR_NAME and similar environmental variables. Of if you cherry-pick or rebase it will modify them.

When you run git format-patch it doesn't provide you with the committer information at all. Likewise when you run git am it doesn't look for the committer information, instead overwriting it with the name and email of whomever is running git am. This will result in a different SHA being created if that information changes.

No easy way to get around it (you would have to hack both format-patch and am to preserve comitter info. However, instead of comparing the commit SHAs you could calculate the commit Patch ID (git patch-id) and compare those. They should be identical.

于 2014-09-30T21:04:40.980 回答