"Robin H. Johnson" <robbat2@xxxxxxxxxx> wrote: > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html