On 1 June 2012 14:49, Rich Freeman <firstname.lastname@example.org> wrote:
> 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.
Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.
Although, I probably could brew up a prototype resigning tool ( based
on Git::PurePerl ,... when they accept and publish my changes ) , just
would be problematic because simply the act of signing a past commit
means the SHA1 of the commit itself is different, so all successive
commits after a re-signed commit will change and also need to be
rebased and re-signed.
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"