1 |
On Sat, 2 Jun 2012 03:25:43 +1200 |
2 |
Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
|
4 |
> On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@g.o> wrote: |
5 |
> >> "git cat-file -p $sha" is as close as you can get to commit objects |
6 |
> >> without needing to write your own decompressing wrapper. But it |
7 |
> >> gives the same results. |
8 |
> > |
9 |
> > Now, does the "signed data" also contain the parent sha? |
10 |
> > |
11 |
> > If yes, our discussion about rebasing is moot, because a rebase |
12 |
> > will in every case destroy previous signatures. |
13 |
> > |
14 |
> |
15 |
> Yes. Which basically means, you *cannot* have both |
16 |
> |
17 |
> a) rebase only merges |
18 |
> and |
19 |
> b) every commit must be signed |
20 |
> |
21 |
> as policies. |
22 |
> |
23 |
> At very best, I think either |
24 |
> a) a future git might support signed rebases ( ie: replacing existing |
25 |
> signatures with new signatures in the name of the person performing |
26 |
> the rebase ) |
27 |
> or |
28 |
> b) somebody could write a wrapper that provides signed-rebase support |
29 |
> until git get around to implementing it natively. |
30 |
> |
31 |
> and even then, you're going to lose original signing info ( Though, |
32 |
> thats no worse than the signer of the manifest file changing every |
33 |
> sign ) |
34 |
|
35 |
Yes, it's no worse so we're practically considering implementing a very |
36 |
complex mechanism for no real benefit. |
37 |
|
38 |
As I see it, as good would be only requiring some kind of 'top-level' |
39 |
commits to be signed. For example, if one does merge a branch |
40 |
to the tree, a signed merge commit should already be good enough for |
41 |
us. Not sure if git is able to do that, however... |
42 |
|
43 |
-- |
44 |
Best regards, |
45 |
Michał Górny |