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