www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: git and deleting branches
Date Wed, 11 Nov 2015 12:43:52 GMT
On Wed, Nov 11, 2015 at 6:39 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> wrote:
> It turns out that so far we haven't spelled out precisely how we need
> to be able to reconstruct the provenance of all the code that we
> release, so we need to start by defining those requirements before
> looking at what's needed for our Git repositories to fulfill them. The
> internal discussions are focusing on this right now.

In a nutshell: with git, a single SHA-1 hash is all that is required
to ensure that you are looking at the right contents and ensure that
you have the complete version history of the contents.  These hashes
are immutable and survive pushes, fetches, and pulls.  Tags and
branches don't have these properties.

The one piece of metadata that we care about that isn't captured by
git is the identity of the authenticated pusher.  That would
correspond in SVN to the committer, for which the longstanding ASF
policy requires an ICLA to be on file.  What git refers to as the
committer may turn out only to be what the ASF refers to as a
contributor.  This identify of the person doing the push would need to
be stored outside of the version history (which, after all is
immutable). Currently this is done with in push logs, but that
requires all pushes to be done to ASF hosted infrastructure.  This
requirement turns out to be unenforceable and easily defeated -- in
fact, ironically the more we tighten the rules for usage of the ASF
clone of the repository the more we drive people to collaborate
elsewhere and only push the final results to the ASF repository.

What we are currently exploring isn't that implementation, but the
requirements for such an implementation.

- Sam Ruby

View raw message