Great. That confirms what I thought. Thanks. On Jul 24, 2011, at 9:37 AM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 24.07.2011 14:16, schrieb Thomas Adam: >> On 24 July 2011 13:12, Mathew Benson <mathew.benson@xxxxxxxxx> wrote: >>> I'm planning to use git for a work project, which requires tight control of the peer review process. In previous jobs, the peer review was a tedious manual process of creating PDF files, writing comments in spreadsheets, and copying comments to the CM system. I want to use technology to my best advantage. >>> >>> Once a developer has completed all his changes in his development branch, what's the best way to get those files to the reviewers, without requiring the author to stop work? First, I think I should create a tag in the developer branch. Each developer has a local repository, and my review tool writes files directly in the work area. Can they just fetch, checkout a tag (don't know how to do that), commit changes, and push it back to the central repository? Is there a better workflow?-- >> >> This is what Gerrit is useful for. > > Yes, Gerrit is a very sophisticated way to do that. > > But you can also achieve a review process by just using git and email > too: Have each developer do each topic of his work on a separate feature > branch and send merge requests (e.g. per email) to the reviewer when he > is done. If the reviewer approves the changes, he merges that branch > (and deletes the remote topic branch, as that topic is now finished and > part of the history). If not, he requests improvements from the developer > who updates that branch and sends another review request when he is done. > We use this approach successfully at my dayjob. -- 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