<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 18, 2014 at 11:31 AM, Samuel Galarneau <span dir="ltr"><<a href="mailto:sgalarneau@digium.com" target="_blank">sgalarneau@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 16, 2014 at 5:01 PM, Russell Bryant <span dir="ltr"><<a href="mailto:russell@russellbryant.net" target="_blank">russell@russellbryant.net</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Sep 16, 2014 at 3:48 PM, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br></span><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>"And there was much rejoicing"<br></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>\o/</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>But seriously, we all know that a lot of people have wanted to move to Git for some time. For the record, everyone at Digium has wanted to move the project to Git for some time. I swore to myself that we wouldn't do another Standard release on Subversion - after we spent at least six weeks mucking around with merge conflicts during Asterisk 12 - and with Asterisk 14 looming ever closer, the time is now to start getting something done on this. <br></div></div></div></div></div></div></blockquote></span></div></div></div></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>...<br></div><span class=""><div>-- Team repos</div><div><br></div><div>I'd recommend just using your own account on github or whatever.</div><div><br></div></span>...<span class=""><div><br></div><div>-- Process Recommendation</div><div><br></div><div>I discussed this a good bit above, but I'm happy to answer questions.</div><span><font color="#888888"><div><br></div><div>-- </div><div>Russell Bryant</div></font></span></span></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Russell,<br><br></div><div class="gmail_extra">how does Gerrit deal with submitting reviews? Are all reviews simply topic branches on the repository that Gerrit hosts?<br></div></div></blockquote><div><br></div><div>Perhaps a real demonstration of workflow would help. I'll use a recent trivial fix that I did. This is a one-liner patch that needed to go into master as well as two stable branches.</div><div><br></div><div>I headed over to my local git tree and created a branch to do the fix.</div><div><br></div><div>$ cd openstack/nova</div><div>$ git checkout -b bug/1370191 origin/master</div><div><br></div><div>... Hack code and commit the fix ...</div><div><br></div><div>$ git commit -a</div><div><br></div><div>Now I have a single patch on top of upstream master that I want to submit for review.</div><div><br></div><div>$ git review</div><div><br></div><div>This created <a href="https://review.openstack.org/#/c/121940/">https://review.openstack.org/#/c/121940/</a></div><div><br></div><div>What's actually happening is a git push to gerrit. A git repo in gerrit maintains all revisions of all patches. You can actually fetch the patch and look at it locally in your tree.</div><div><br></div><div>$ git fetch <a href="https://review.openstack.org/openstack/nova">https://review.openstack.org/openstack/nova</a> refs/changes/40/121940/1 && git checkout FETCH_HEAD<br></div><div><br></div><div>or as a shortcut:</div><div><br></div><div>$ git review -d 121940</div><div><br></div><div>From there a few CI systems ran tests against the patch automatically and posted their results to the review. Also, some people reviewed the code and it was approved and automatically merged.</div><div><br></div><div>Let's say that someone found a bug in my patch and I needed to update it. That process would be:</div><div><br></div><div>... Hack the code and then amend the commit ...</div><div><br></div><div>$ git commit -a --amend</div><div>$ git review</div><div><br></div><div>That git-review would push a second revision to the existing code review.</div><div><br></div><div>Once my patch against master was merged, I wanted to propose it for merging into the stable branches. You can do this manually (make a local branch based on upstream stable, cherry-pick the commit, and git-review). In this case, the patch was trivial and had no conflicts, so I was able to just press the "Cherry-pick to branch" button in gerrit. The result is 3 code reviews:</div><div><br></div><div><a href="https://review.openstack.org/#/q/I93b370d6457d2e85493be01a62a76404d228a6fa,n,z">https://review.openstack.org/#/q/I93b370d6457d2e85493be01a62a76404d228a6fa,n,z</a><br></div><div><br></div><div>My stable backports are still under review at the time of writing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">What about a pull request workflow where the repository is forked during development, can Gerrit support this in some way? Just trying to understand how team repos on Github or some other platform could be used for development purposes.</div></div></blockquote><div><br></div><div>Sure. This case would be a bit of an expansion on the above. Let's say you're working on something a bit more involved. Your feature may be a series of 15 commits. Since you're doing so much work, you don't want it to only exist on your hard drive. So, you periodically push a branch to github for both visibility and backup purposes. When you're ready for review, you just run git-review as usual.</div><div><br></div><div>When you go to post the review, git-review will warn you and say something like "you're about to push more than 1 patch up for review, are you sure that's what you want?". Yes, it is indeed what you want.</div><div><br></div><div>At that point, you would have 15 new code reviews created. Gerrit understands that these are all related and notes the dependencies between them.</div><div><br></div><div>One example would be <a href="https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/convert-ec2-api-to-use-nova-objects,n,z">https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/convert-ec2-api-to-use-nova-objects,n,z</a></div><div><br></div><div>Take a look at a specific patch like this one: <a href="https://review.openstack.org/#/c/113389/">https://review.openstack.org/#/c/113389/</a></div><div><br></div><div>Find the "Dependencies" section on the review and expand it. You'll see that this patch was one in the middle of a patch series. It depended on one patch and another patch depended on this one.</div><div><br></div><div>Hope that helps,</div><div><br></div><div>-- </div><div>Russell Bryant</div></div></div></div>