1 |
On 1 June 2012 14:49, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Thu, May 31, 2012 at 5:52 PM, Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
>> Just I haven't worked out what happens when the SHA1 of the 'parent' |
4 |
>> header changes, which *will* change if the rebase is anything other |
5 |
>> than a fast-forward. |
6 |
>> |
7 |
>> If that SHA1 changes, the gpg signature will surely fail? |
8 |
> |
9 |
> Rebasing doesn't modify past commits - it creates new ones and the |
10 |
> past ones are no longer in the history of the current head. So, it |
11 |
> doesn't break the old signatures so much as discard them. You would |
12 |
> need to create new signatures in their place, presumably from whoever |
13 |
> performed the rebase. |
14 |
|
15 |
|
16 |
Hmm, thats annoying. Almost makes me wish it was the trees that were |
17 |
signed, not the commits. |
18 |
|
19 |
Although, I probably could brew up a prototype resigning tool ( based |
20 |
on Git::PurePerl ,... when they accept and publish my changes ) , just |
21 |
would be problematic because simply the act of signing a past commit |
22 |
means the SHA1 of the commit itself is different, so all successive |
23 |
commits after a re-signed commit will change and also need to be |
24 |
rebased and re-signed. |
25 |
|
26 |
-- |
27 |
Kent |
28 |
|
29 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
30 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
31 |
|
32 |
http://kent-fredric.fox.geek.nz |