如何在交互式rebase压缩后保留提交gpg-signature？

Question

当我想通过交互式rebase压缩一些提交时：

git rebase -i HEAD~3

然后：

pick cbd03e3 Final commit (signed)
s f522f5d bla-bla-bla (signed)
s 09a7b7c bla-bla (signed)

# Rebase c2e142e..09a7b7c onto c2e142e
...

尽管所有提交都具有相同的签名，但最终提交还没有gpg签名。是否可以在交互式rebase压缩后保留提交gpg-signature？

Answer 1

就像Cupcake所说的那样，你不能保留未撤销提交中的旧签名，但如果你像这样重新设置，你可以签署新的压缩提交：

git rebase --interactive --gpg-sign=myemail@example.com HEAD~4

添加--gpg-sign=myemail@example.com作为参数将签署最终压缩的提交。

Answer 2

你能做到没有意义。 gpg签名的重点是验证代码是否未被篡改。如果您在修改历史记录后可以保留签名，那将会破坏整个目的。

我目前没有使用gpg签署我的Git代码，所以我不知道确切的细节，但我想它可能会破坏树的最终提交对象。当您在示例中进行rebase时，Final commit将具有不同的sha1 ID，因此它与rebase之前的对象不同，因此具有相同的gpg签名可能是不可能的，就像我说的那样，它不会'有道理。

Answer 3

为了强化您不会在重新提交的提交上保留签名的事实，git 2.9.x +（2016年第3季度）将明确指出demo Phoenix project不会检查签名（因为rebase部分会丢失签名）

git pull --rebase见commit c57e501（2016年5月20日） ^{（由Alexander Hirsch (``)合并于Junio C Hamano -- gitster --，2016年6月20日）}

  

pull：使用--verify-signatures

警告--rebase      

git-pull默认忽略--verify-signatures选项   运行--rebase，可能会让用户相信   rebase操作将检查有效的GPG签名。

     

对--verify-signatures实施git rebase进行了讨论，   但对有效工作流程的疑虑却上升了。既然你经常合并   其他分支机构进入您的分支机构您可能会感兴趣   他们的一方有一个有效的GPG签名。

     另一方面，

重新定位是重建您的分支   其他人的工作，为了推动结果，为时已晚   即使你发现他们的承诺缺乏可接受性，也要拒绝他们的工作   签名

     

让我们警告用户忽略--verify-signatures选项   期间＆＃34; pull --rebase＆＃34 ;; 用户不会想知道如果会发生什么   他们的提交缺乏可接受的签名。

Answer 4

一种选择是将 commit.gpgSign 设置为 true。这将始终签署包括重新提交的提交。

要在本地存储库中执行此操作：

git config commit.gpgSign true

在全球范围内进行：

git config --global commit.gpgSign true