5

Let's assume a git repository where the following hold true:

  • Most commits are signed.
  • Rebases are often used, so as to have a clean history.
  • Sometimes multiple persons work on the same branch.
  • Signing a commit is assumed to mean signing the equivalent diff, not signing the entire state of the repo (despite signed commits also signing hash of ancestors)

Now, I want to rebase a branch where I did part of the work and a co-worker pushed some commits ; and I'd like to "keep" signatures on the commits I made (ie. re-sign all commits I made with the new history, even in case of merge conflict), but not to sign work not written by me (ie. I prefer losing signatures on commits from my coworker than signing them).

I could use git rebase -S (like proposed in answers to this question) ; but that would also sign commits from my co-worker.

Is there a way to do this?

Ekleog
  • 1,054
  • 7
  • 19

1 Answers1

2

Keep in mind that this is a hacky answer, You should strongly consider Cupcake@ answer as a blocker for what you're trying to do. (even if you only sign the "diff" introduced by a commit, what happens if you have a conflict during the rebase ? who signs the code introduced by the conflict resolution ?)

That said, what you could do is rebase, loose the gpg signatures. And then with git filter-branch do some magic to re-gpg-sign the commits authored by you with your key, and the commits authored by someone else with their key.

Community
  • 1
  • 1
bperson
  • 1,285
  • 10
  • 19
  • This seems to point to the direction of just accepting that the history is not 'clean', and using signed merges instead of rebases. – Iizuki Sep 02 '22 at 07:39