[asterisk-dev] Git Migration

[Russell Bryant]

On Thu, Sep 18, 2014 at 11:31 AM, Samuel Galarneau <sgalarneau at digium.com>
wrote:

>
>
> On Tue, Sep 16, 2014 at 5:01 PM, Russell Bryant <russell at russellbryant.net
> > wrote:
>
>> On Tue, Sep 16, 2014 at 3:48 PM, Matthew Jordan <mjordan at digium.com>
>> wrote:
>>
>>> "And there was much rejoicing"
>>>
>>
>> \o/
>>
>>
>>> 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.
>>>
>> ...
>> -- Team repos
>>
>> I'd recommend just using your own account on github or whatever.
>>
>> ...
>>
>> -- Process Recommendation
>>
>> I discussed this a good bit above, but I'm happy to answer questions.
>>
>> --
>> Russell Bryant
>>
>
> Russell,
>
> how does Gerrit deal with submitting reviews? Are all reviews simply topic
> branches on the repository that Gerrit hosts?
>

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.

I headed over to my local git tree and created a branch to do the fix.

$ cd openstack/nova
$ git checkout -b bug/1370191 origin/master

... Hack code and commit the fix ...

$ git commit -a

Now I have a single patch on top of upstream master that I want to submit
for review.

$ git review

This created https://review.openstack.org/#/c/121940/

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.

$ git fetch https://review.openstack.org/openstack/nova
refs/changes/40/121940/1 && git checkout FETCH_HEAD

or as a shortcut:

$ git review -d 121940

>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.

Let's say that someone found a bug in my patch and I needed to update it.
 That process would be:

... Hack the code and then amend the commit ...

$ git commit -a --amend
$ git review

That git-review would push a second revision to the existing code review.

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:

https://review.openstack.org/#/q/I93b370d6457d2e85493be01a62a76404d228a6fa,n,z

My stable backports are still under review at the time of writing.

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.
>

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.

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.

At that point, you would have 15 new code reviews created.  Gerrit
understands that these are all related and notes the dependencies between
them.

One example would be
https://review.openstack.org/#/q/status:merged+project:openstack/nova+branch:master+topic:bp/convert-ec2-api-to-use-nova-objects,n,z

Take a look at a specific patch like this one:
https://review.openstack.org/#/c/113389/

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.

Hope that helps,

-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140918/aca85859/attachment-0001.html>