34

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?

Alexander Yancharuk
  • 12,892
  • 5
  • 49
  • 54
  • "that all of those commits have same signature" this doesn't make any sense. You're probably generating the *different* signatures from the same key, but the signatures themself can not be the same. – chpio May 07 '21 at 09:35

4 Answers4

65

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.

samurailink3
  • 790
  • 6
  • 7
13

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.

  • 2
    It makes sense if they are YOUR commits, and you want to retain A signature (rather than THE signature). – Andy Hayden Nov 08 '16 at 20:06
  • @AndyHayden then you should resign the commits. it has helped me conceptually to prior to rebasing checkout a new branch. I am working on work-01. I do `git checkout work-02`. I rebase, resolve merge conflicts, and squash commits as appropriate. work-01 has not changed at all. the commits are all still there and as they were. some of the commits might also exist in work-02, some might be nearly identical but if a single character has changed it has a new commit hash id. this exercise helped me understand git rebasing. – emory Jan 24 '18 at 18:57
  • 2
    This is interesting, but I wonder if it's 100% valid. We work on feature branches and our Gitlab is configured to allow MRs only if they can be fast-forwarded (quasi-linear history), so we rebase those branches if something has changed in base branch. When I commit to feature branch and sign commit, then my colleague rebases branch, GPG signature should remain untouched IF commit is picked without changes (so my signature is still valid, because it is the exact code that I commited and signed). However GPG signature is lost when signed commit is rebased by other person (we've just checked it). – Wirone Mar 20 '18 at 08:42
4

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.

VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
3

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
PiotrWolkowski
  • 7,942
  • 6
  • 43
  • 65