Git sign previous commits keeping dates

Sometimes you might need to re-sign your previous commits using GnuPG. This process rewrites the git history in a sense of changing commit hashes. What is more, it also changes the date when commit was made. If not done properly, the repository looks like if there was no history at all after signing all the previous work, as all the commits would look as if they were added in the same instance. You cannot even create such a scenario by hand, so it looks very unnatural.

Warning: Before proceeding make absolutely sure you have multiple backups of your work. Failing to do so may lead to loss of data.

Consider the following command usually used to sign previous commits:

git rebase --exec 'git commit --amend --no-edit --no-verify -S' -i --root

This creates the following interactive rebase window (truncated):

pick 60dcc7e insert posts sources
exec git commit --amend --no-edit --no-verify -S
pick 989ea13 fix sources links
exec git commit --amend --no-edit --no-verify -S
pick ce0cab2 move gcal push hook from gists to sources
exec git commit --amend --no-edit --no-verify -S
...

After saving and closing, the process of rebasing takes a few seconds. The result can be checked like this:

git log --pretty=fuller

We can find out that the AuthorDate property was left untouched but the CommitDate is adjusted to the point when the command is being run:

commit 7c378e312bb6ab0f8265707be39f343cf04f6d25 (HEAD -> master)
Author:     Peter Babič <[email protected]>
AuthorDate: Thu Nov 25 19:18:03 2021 +0100
Commit:     Peter Babič <[email protected]>
CommitDate: Sun Nov 28 20:16:56 2021 +0100

    insert links

commit f32a1fc98c829c6ee8bb8dbcda46345f2c00dedd
Author:     Peter Babič <[email protected]>
AuthorDate: Wed Jul 28 21:57:02 2021 +0200
Commit:     Peter Babič <[email protected]>
CommitDate: Sun Nov 28 20:16:54 2021 +0100

    insert post cypress husky stop-only

commit 86c263cb83bb629c5f9dd20d81808a21c83f1ff8
Author:     Peter Babič <[email protected]>
AuthorDate: Thu Jul 15 19:56:13 2021 +0200
Commit:     Peter Babič <[email protected]>
CommitDate: Sun Nov 28 20:16:52 2021 +0100

    update source to show differences

...

Because I thought there would be a single command to work around this, I have had some hard times. When I screwed up, I could fortunately always go back and start over by looking at the entry at the very bottom of git reflog, noting it's number and resetting the repository state via:

git reset --hard HEAD@{xx}

The trial and error went for some time as I tried multiple different commands, until I found this little unappreciated gem. This is the single place I could found that shows the process actually requires two rebase commands that are fired one after the other, with the second one added here:

git rebase --exec 'git commit --amend --no-edit --no-verify -S' -i --root
git rebase --committer-date-is-author-date -i --root

The above command fixes the CommitDate to match the AuthorDate after the first rebase, check again yourself:

git log --pretty=fuller

Now the AuthorDate and CommitDate match perfectly:

commit ee8972f2ca725cfe297417f5cd5ed76816b4b0bc (HEAD -> master, origin/master)
Author:     Peter Babič <[email protected]>
AuthorDate: Thu Nov 25 19:18:03 2021 +0100
Commit:     Peter Babič <[email protected]>
CommitDate: Thu Nov 25 19:18:03 2021 +0100

    insert links

commit 583d8b7a934f10faa6ee574180192e4e2b98e706
Author:     Peter Babič <[email protected]>
AuthorDate: Wed Jul 28 21:57:02 2021 +0200
Commit:     Peter Babič <[email protected]>
CommitDate: Wed Jul 28 21:57:02 2021 +0200

    insert post cypress husky stop-only

commit 0760e7be4286f6b607243b1c712828d0161311e0
Author:     Peter Babič <[email protected]>
AuthorDate: Thu Jul 15 19:56:13 2021 +0200
Commit:     Peter Babič <[email protected]>
CommitDate: Thu Jul 15 19:56:13 2021 +0200

    update source to show differences

...

There might be a way to do this in a single rebase, not requiring two separate ones, but I was not able to find a way to achieve this. Anyway, one command or two, it does not matter as long as the job get's done, unless you do this for thousands of commits, because the process is a little time-consuming. Keep in mind that rewriting thousands of commits would be suspicious at the very least. There is still a trace left after this activity:

git log --show-signature

Which produces a slightly different output:

commit 819bd4412b97f295dac5c958b18464d38accb94b (HEAD -> master)
gpg: Signature made Sun 28 Nov 2021 20:26:29 CET
gpg:                using RSA key 0575E586224E3E33CF1A3EE34BB075BC1884BA40
gpg: Good signature from "Peter Babic <[email protected]>" [ultimate]
Primary key fingerprint: A44B 03E6 42BB 4223 6780  FEA4 3A13 81FC F273 8E75
     Subkey fingerprint: 0575 E586 224E 3E33 CF1A  3EE3 4BB0 75BC 1884 BA40
Author: Peter Babič <[email protected]>
Date:   Thu Nov 25 19:18:03 2021 +0100

    insert links

commit 24634bdeafda0cbddb7c3e7dec368762a3e790b5
gpg: Signature made Sun 28 Nov 2021 20:26:28 CET
gpg:                using RSA key 0575E586224E3E33CF1A3EE34BB075BC1884BA40
gpg: Good signature from "Peter Babic <[email protected]>" [ultimate]
Primary key fingerprint: A44B 03E6 42BB 4223 6780  FEA4 3A13 81FC F273 8E75
     Subkey fingerprint: 0575 E586 224E 3E33 CF1A  3EE3 4BB0 75BC 1884 BA40
Author: Peter Babič <[email protected]>
Date:   Wed Jul 28 21:57:02 2021 +0200

    insert post cypress husky stop-only

commit 86a49348e4a870f0fc4e7894d9766dc72acb1482
gpg: Signature made Sun 28 Nov 2021 20:26:27 CET
gpg:                using RSA key 0575E586224E3E33CF1A3EE34BB075BC1884BA40
gpg: Good signature from "Peter Babic <[email protected]>" [ultimate]
Primary key fingerprint: A44B 03E6 42BB 4223 6780  FEA4 3A13 81FC F273 8E75
     Subkey fingerprint: 0575 E586 224E 3E33 CF1A  3EE3 4BB0 75BC 1884 BA40
Author: Peter Babič <[email protected]>
Date:   Thu Jul 15 19:56:13 2021 +0200

    update source to show differences

...

The above shows the Date properly, however gpg: Signature made is saved the instant the rebasing is done. I did not try to work around this, because I was pretty happy with the result as is. Thinking about it, it might not even make sense to have something signed with a key from the "future". Enjoy!

Links