"Robin H. Johnson" <robbat2@xxxxxxxxxx> wrote: > On Wed, Apr 15, 2009 at 12:20:54PM -0700, Shawn O. Pearce wrote: > > > 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. > > All pushing to the central repo will be git+ssh:// anyway. > > I don't follow where the PM's identity is being stored, and how that's > distributed back out with the later pulls. Its stored in the reflog for the branch; see "git log -g branch". Technically the environment variable GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL is used to populate the identity into the reflog, but if these aren't set then its guessed from the gecos information of the effective user. > The other downside to relying on SSH presentation of identity directly, > is the inability to use the SSH key to uniquely identify the user during > the SSH auth (see designs like gitosis, where you always push to > git+ssh://git@host/repo). Uhm, yea. That's a fault of gitosis then. It knows the key that was used, and has that mapped back to some token that identifies that account in the configuration file. Why it doesn't push that into the GIT_COMMITTER_* environment before launching git-shell, I don't know. <plug type="shameless"> My day-job project, Gerrit Code Review[1], actually does the right thing by recording the identity of the user in the reflog... </plug> [1] http://code.google.com/p/gerrit/ -- 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