On Sat, 2 Jun 2012 03:25:43 +1200
Kent Fredric <kentfredric@...> wrote:
> On 2 June 2012 03:12, Andreas K. Huettel <firstname.lastname@example.org> wrote:
> >> "git cat-file -p $sha" is as close as you can get to commit objects
> >> without needing to write your own decompressing wrapper. But it
> >> gives the same results.
> > Now, does the "signed data" also contain the parent sha?
> > If yes, our discussion about rebasing is moot, because a rebase
> > will in every case destroy previous signatures.
> Yes. Which basically means, you *cannot* have both
> a) rebase only merges
> b) every commit must be signed
> as policies.
> At very best, I think either
> a) a future git might support signed rebases ( ie: replacing existing
> signatures with new signatures in the name of the person performing
> the rebase )
> b) somebody could write a wrapper that provides signed-rebase support
> until git get around to implementing it natively.
> and even then, you're going to lose original signing info ( Though,
> thats no worse than the signer of the manifest file changing every
> sign )
Yes, it's no worse so we're practically considering implementing a very
complex mechanism for no real benefit.
As I see it, as good would be only requiring some kind of 'top-level'
commits to be signed. For example, if one does merge a branch
to the tree, a signed merge commit should already be good enough for
us. Not sure if git is able to do that, however...