Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: kentfredric@×××××.com
Subject: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
Date: Fri, 01 Jun 2012 15:39:37
Message-Id: 20120601173939.6bc00c6e@pomiocik.lan
In Reply to: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver by Kent Fredric
On Sat, 2 Jun 2012 03:25:43 +1200
Kent Fredric <kentfredric@×××××.com> wrote:

> On 2 June 2012 03:12, Andreas K. Huettel <dilfridge@g.o> 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 > and > 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 ) > or > 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... -- Best regards, Michał Górny


File name MIME type
signature.asc application/pgp-signature