How to retain commit gpg-signature after interactive rebase squashing?

Question

When I want to squash some commits by interactive rebase:

git rebase -i HEAD~3

And then:

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

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

The final commit haven't gpg-signature despite that all of those commits have same signature. Is it possible to retain commit gpg-signature after interactive rebase squash?

Answer 1

Like Cupcake stated, you can't retain the old signature from the unsquashed commits, but you can sign the new squashed commit if you rebase like this:

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

Adding --gpg-sign=myemail@example.com as an argument will sign the final squashed commit.

Answer 2

It doesn't make sense that you would be able to. The whole point of a gpg signature is to verify that code hasn't been tampered with. If you could keep the signature after modifying the history, that would defeat the whole purpose.

I don't currently sign my Git code with gpg so I don't know the exact details, but I guess it probably hashes the final commit object of a tree. When you rebase like in your example, the Final commit will have a different sha1 ID, so it's not the same object as before the rebase, so having the same gpg signature is probably impossible, and like I said, it wouldn't make sense.

Answer 3

To reinforce the fact you don't keep signature on rebased commits, git 2.9.x+ (Q3 2016) will clearly state that a git pull --rebase would not check signature (since the rebase part would lost them)

See commit c57e501 (20 May 2016) by Alexander Hirsch (``).
^{(Merged by Junio C Hamano -- gitster -- in commit 73bc4b4, 20 Jun 2016)}

pull: warn on --verify-signatures with --rebase

git-pull silently ignores the --verify-signatures option when running --rebase, potentially leaving users in the belief that the rebase operation would check for valid GPG signatures.

Implementing --verify-signatures for git rebase was talked about, but doubts for a valid workflow rose up. Since you usually merge other's branches into your branch you might have an interest that their side has a valid GPG signature.

Rebasing, on the other hand, is to rebuild your branch on top of other's work, in order to push the result back, and it is too late to reject their work even if you find their commits lack acceptable signature.

Let's warn users that the --verify-signatures option is ignored during "pull --rebase"; users do not wonder what would happen if their commits lack acceptable signature that way.

Answer 4

One option is to set a commit.gpgSign setting to true. This will always sign the commits including the rebased commits.

To do it locally in a repo:

git config commit.gpgSign true

To do it globally:

git config --global commit.gpgSign true