Re: Tracability in git commits

["Martin Langhoff" <martin.langhoff@gmail.com>]

On Wed, Apr 30, 2008 at 10:32 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>  The project I'm thinking about is OpenEmbedded which used to use
>  bitkeeper and switched to monotone when bitkeeper went private only.

Richard,

you might be able to use a slightly tweaked workflow where you

 1 - Prepare a GPG-signed list of the commit hashes you are about to push
 2 - Push to an "incoming" repository that does weak or no validation
 3 - Push/publish your GPG-signed list of commit hashes
 4 - A script "pushes" commits from the "incoming" repo to a
"verified" repo after checking that they are backed by a GPG-signed
list. For ease of use, this can happen on the server ASAP, and it can
be validated independently by any party. Notably, it is probably a
good idea that it is validated shortly before a release is tagged.

This way, you keep the flexible/fast properties of git, but use the
SHA1 commit->tree>file relationship plus external wrapper scripts to
add auditing capabilities that are open and repeatable.

So all you need is

 - a trivial "push" wrapper that prepares the commits-to-push list and
automates the signing and publishing of the list
 - a trivial script to run the migration of verified commits

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff