1 |
On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@g.o> wrote: |
2 |
>> "git cat-file -p $sha" is as close as you can get to commit objects |
3 |
>> without needing to write your own decompressing wrapper. But it gives |
4 |
>> the same results. |
5 |
> |
6 |
> Now, does the "signed data" also contain the parent sha? |
7 |
> |
8 |
> If yes, our discussion about rebasing is moot, because a rebase will in every |
9 |
> case destroy previous signatures. |
10 |
> |
11 |
|
12 |
Yes. Which basically means, you *cannot* have both |
13 |
|
14 |
a) rebase only merges |
15 |
and |
16 |
b) every commit must be signed |
17 |
|
18 |
as policies. |
19 |
|
20 |
At very best, I think either |
21 |
a) a future git might support signed rebases ( ie: replacing existing |
22 |
signatures with new signatures in the name of the person performing |
23 |
the rebase ) |
24 |
or |
25 |
b) somebody could write a wrapper that provides signed-rebase support |
26 |
until git get around to implementing it natively. |
27 |
|
28 |
and even then, you're going to lose original signing info ( Though, |
29 |
thats no worse than the signer of the manifest file changing every |
30 |
sign ) |
31 |
|
32 |
|
33 |
-- |
34 |
Kent |
35 |
|
36 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
37 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
38 |
|
39 |
http://kent-fredric.fox.geek.nz |