我已经在一个库上乱砍了很长一段时间，并在我的private存储库中进行了很多提交：
A -> B -> C -> D -> E
最后，我即将完成第一个版本，并希望将其发布到public之前的D远程版本，然后将A..C保留给自己，{{1}之后应该是这样的：
public根据要求，我希望能够证明我是如何到达D -> E
的（考虑版权声明等）。至于（目前），根据时间和变更集对链中提交的哈希进行逆向工程几乎是不可能的，我认为保持D的父D指针将是其中之一git的天才优势。可悲的是，我无法找到实际工作的方法。
那么，我如何将C推送到D -> E，使其成为一个功能齐全的公共存储库，其中包含所有必需的对象，以便结帐public或D和{{1仍然指向E作为父级？
D据我所知，压缩C会引入一个新的提交，删除指向git push public D..E:master
error: src refspec D..E does not match any.
error: failed to push some refs to '<public>'
的父指针，从而消除A..D存在的可证明性。 （简单示例：说C反转A..C，那么在某些时候你永远无法证明C在那里。）
我显然可以在壁球提交的描述中手动记下B的哈希值，但是已经有一个B指针字段，为什么不使用它呢？
另外，为了对公众做出进一步的改变，我必须在这个新的压缩提交之上修改我的私人分支，这似乎是错误的......
我认为我找到了一个解决方案，首先创建一个具有所需深度的本地克隆C，然后将该克隆推送到parent，如下所示：
local_public使用
public我可以验证git clone --depth 2 file:///<abspath_private> local_public
只包含git log --pretty=raw
，并且提交，树和父哈希是相同的，这正是我想要的。
问题在于，当我尝试从local_public推送添加的D -> E远程时，我收到如下错误：
public任何想法如何使这项工作？
答案 0 :(得分：1)
您想要的不可能。
在Git中工作就像一个链表。每次提交都有父提交的ID（如果是root提交，则为null）...父提交的ID是提交标识的一部分。
推D - ＆gt; E到repo，你需要修改D的父级，这将导致D的HASH改变，这反过来又要求E的散列也改变（因为E将有一个新的父级）。 / p>