On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric@...> 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
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.