Re: GPG signing for git commit?

From: Shawn O. Pearce <spearce@spearce.org>
Date: Apr 15, 2009, 19:20 UTC
Message-ID: <20090415192054.GE23604@spearce.org>
In-Reply-To: <20090415185554.GG23644@curie-int>

"Robin H. Johnson" <robbat2@gentoo.org> wrote:

Show 15 quoted lines

> 
> One of the spots that we're looking for in this, is a model something
> like what follows. Firstly, a "proxy maintainer" (PM) is a developer
> with commit rights to the central repo, that's willing to proxy commits
> by an outside source for some specific package. Think of them as the
> kernel subsystem maintainer, but many more of them. The PM is still
> expected to verify the work before passing it on the central repo.
> 
> So we have a commit with author+committer being the outside source, and
> now we want to record (in an easily reviewable fashion) that a specific
> changeset was introduced to the central tree by the PM.
> 
> Not sure of the best route to trace this data. Signing the SHA1 makes
> the most sense, but need to be able to do that without polluting the tag
> namespace.

Have the PM push over SSH, and don't ever expire reflogs on the central repository? The reflog will have the old and new commits and the user name of the PM.

Downsides are:

- data is in the reflog on the central repository, to access it
  you need to expose that file via some non-git means (e.g. http
  or direct shell).

- one reflog record may cover multiple commits, so looking up a
  single commit is very difficult.  no current tools exist to merge
  the reflog back against the commit history to attach the record
  to a range of commits.

- the reflog is a text file, it will get somewhat large with time.

- the reflog is destroyed when the branch is deleted.  you may need a
  hook to forbid deletion of critical branches, so the reflog stays.

-- 
Shawn.