Re: Tracability in git commits

From: Junio C Hamano <gitster@pobox.com>
Date: May 1, 2008, 19:03 UTC
Message-ID: <7v63txzw18.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <46a038f90805010034y3ffd3eb5hbee7c2200912eef3@mail.gmail.com>

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

Show 21 quoted lines

> On Thu, May 1, 2008 at 1:26 PM, Martin Langhoff
> <martin.langhoff@gmail.com> wrote:
>>   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
>
> Note that with this, you *can* also keep the ability for someone to
> push commits that they are not the author or committer for. This is
> actually added flexibility - you can merge from a 3rd party tree, and
> push it to the central repo, as long as you GPG-sign the list
> including those commits.
>
> I highlight "can" because the wrapper on the developer side and the
> script on the server side can prevent this, or force extra steps in
> such case.
>
> cheers,

I suspect that, with the "push to incoming, vet there and move to verified" workflow, you do not need a special GPG-signed list. You can instead have the pusher sign the tip using the usual signed-tag mechanism, which would sign the whole history leading to it, and have him push that tag to the incoming together with the tip update. You obviously do not need nor want to move that signed tag to the final area.