| 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 |
Archives