Hi Brock, Brock Peabody wrote: > Developers wishing to contribute code would push revisions to the gatekeepers' > repos, who after reviewing the revisions would push them to the Master > repository, from which developers would have only pull access. [...] > This works fine, except for the fact that there is no trail in the master > repository indicating which GateKeeper approved which revision. [...] > I've seen evidence of what we're after - by browsing the repository of git > itself. Each revision in it contains an "Author" field and a (frequently > different) "Committer" field. Furthermore, there are often multiple > "Signed-off-by" and "Acked by" logs. How are these fields populated? In the Linux kernel and similar projects, there is a sharp distinction between patch authors and committers[1]. The life cycle of a patch is something like this: A patch is written and a rough version is mailed to interested parties. ‘git format-patch’ or ‘git request-pull’ can be useful for this. The patch is discussed. Subsystem maintainers, reviewers, testers, and others try out the patch and form an opinion on whether it is “cooked” or needs more improvements. Some of these people (including the original author) might suggest improved versions of the patch; each person doing so adds her name to the bottom of the Signed-off-by list to indicate that to the best of her knowledge the updated patch is not proprietary but is suitable for inclusion in the project. At a certain point, the patch is ready. A committer applies it, adding appropriate Acked-by etc headers to summarize the discussion for reference when the code breaks :). ‘git am -s’ can take care of adding the sign-off in this case. The trajectory of the patch afterwards can be tracked through merges. The commit passes through a hierarchy of maintainers, usually with the help of ‘git request-pull’. There is no need to recertify origin at this point, since the commit object is already set in stone. ----- Wait a second. The patch is never in a git tree until it is fully cooked? Well, no, as long as it is made clear, it is perfectly fine to publish a patch as a commit before it is cooked. But the relevant git branches at this point are just a distribution medium, and those commits are not meant to be pulled by anyone upstream. Once the patches seem cooked, a person can _propose_ a branch to be pulled. If that branch is completely broken, it is back to the drawing board, and a new branch is made, usually with the help of ‘git rebase --interactive’, or ‘git reset’ followed by ‘git add --patch’. ----- Why not keep the false starts? Why such concern with history? To get maximum utility out of ‘git bisect’, it is best if each commit builds cleanly and the result is not too broken. To get maximum utility out of ‘git log --grep’ and ‘git log -S’, it is best if the commit log clearly and logically explains the design of the current code. Probably only some of these concerns will apply in your case, but I thought I should explain the story as well as I could. Hope that helps, Jonathan [1] I am thinking in particular of this message as I write: http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744 -- 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