Re: Tracability in git commits

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 1, 2008, 01:26 UTC
Message-ID: <46a038f90804301826xaf5d73bl1d29a07bc930a716@mail.gmail.com>
In-Reply-To: <1209551520.5010.20.camel@dax.rpnet.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,

-- 
 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