On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfred...@gmail.com> wrote: > Just I haven't worked out what happens when the SHA1 of the 'parent' > header changes, which *will* change if the rebase is anything other > than a fast-forward. > > If that SHA1 changes, the gpg signature will surely fail?
Rebasing doesn't modify past commits - it creates new ones and the past ones are no longer in the history of the current head. So, it doesn't break the old signatures so much as discard them. You would need to create new signatures in their place, presumably from whoever performed the rebase. I'm trying to glean what I can from the little info out there about how the new commit signatures work, but I don't think that you can use signatures to convey authorship if later authors are going to rebase the branch. The situation is not unlike what we have now with manifests. As far as I can tell if you want to do work outside of master, and then get those commits into master but preserve all the past signatures in the history of master, then you'd need to do a merge commit, so that all the deltas to do the merge are in a separate commit which is then signed by the person doing the merge. Rich
