Open Stack

On Fri, Mar 1, 2013 at 8:21 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 03/01/2013 10:43 AM, Ilya Persky wrote:
> > Hi Guys!
> >
> > Consider the following situation: we registered a blueprint
> > (my-blueprint) which requires a lot of coding. Say this blueprint
> > describes a way for creating unit tests for some big part of code.
> > It is generally a good practice not to include all this code in a huge
> > commit which can become a cause of multiple conflicts and reviewers'
> > headache, but to break it into a series of small independent commits (in
> > our example: consistent subsets of unit tests for independent modules
> e.g.).
> >
> > My question is: what is the right way to publish such series of commits?
> >
> > Say, I created a topic "bp/my-blueprint" which points to last upstream
> > commit and then I made three commits:
> >
> > upstream_HEAD -> bp_commit_A -> bp_commit_B -> bp_commit_C
> >
> > Is this a good practice to execute "git review" for each of these
> > commits? I see a lot of problems here: bp_commit_B can't be merged until
> > bp_commit_A is merged, etc. Or I'll have to rebase all of them somehow.
> >
> > Another way is to create multiple topic branches for each of the commits:
> >
> > bp/my-blueprint1: upstream_HEAD -> bp_commit_A
> > bp/my-blueprint2: upstream_HEAD -> bp_commit_B
> > bp/my-blueprint3: upstream_HEAD -> bp_commit_C
> >
> > This doesn't look pretty and I don't know then what is the right way to
> > name such topics.
> >
> > What do you think?..
>
> Just run "git review" a single time with your tree set up like your
> first example.  It will upload all three changes and will keep track of
> the fact that C depends on B which depends on A.  It will ensure that
> they can only be merged in order.
>
>
To expand on that a bit, using the example of:
  upstream -> commit-A -> commit-B -> commit-C
you can "git review" at this point, like Russell said, and gerrit will
understand the dependency (and even display it to reviewers :) ). For
example, this might create three gerrit reviews numbered 123, 124, 125.

However, if someone spots an issue in your code, let's say in commit-B,
updating that review may seem a bit tricky at first, but it isn't that bad.
Here's what to do:

* make sure you've checked out commit C. It should be the same SHA as in
the review in gerrit. (Tip: "git review -d 125" will check this out to a
local branch)
* "git rebase -i HEAD~3"
This will open your $EDITOR. Replace "pick" with "edit" for the commit-B
line. I suggest "HEAD~3" in this case since that is your distance back to
where you diverged from master, but "HEAD~2" would also work. Don't "git
rebase master" at this point -- it's harder for reviewers if you mix a real
rebase with some new edits in the same review...
* edit your changes, and "git add" them (but don't commit)
* "git rebase --continue"
* "git review -R". Note the "-R" is really important here.

That "-R" tells gerrit to be smart about how it rebases your commits. In
this case, it won't have any effect on the review for commit A, it will
post your change to commit B, and it will automatically rebase commit C,
and detect that C was a trivial rebase, so all the votes on it still count
(though approvals need to be re-granted, IIRC).

There's lots more info here: https://wiki.openstack.org/wiki/GerritWorkflow

HTH :)

--
Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130301/8fac61f1/attachment.html>