Open Stack

Hi Evgeny and Doug,

So the thing to keep in mind is that Gerrit determines a new review by
the change-id in the commit message.  It then determines patch sets by
the commit hashes.  This is my understanding of it at least.  A commit's
hash gets changed on many actions such as cherry-picks, rebases, and
commit --amend.

With this in mind, this means that you can verify if your changes will
not cause an update to the ancestor changes in a gerrit dependency
chain.  Before you do a git review just look at your git log and commit
hashes and see if the hash for each of those commits are the same as the
latest patch sets in gerrit.

My workflow is this:
If I just need to rebase the change, I just hit the rebase button in
gerrit on my change only.  This will cause the commit to have a new
hash, thus a new patch set.

If I need to make a change then just doing the normal git checkout from
the gerrit change page, and git commit --amend works fine, because I am
only touching that commit.

If I need to make a change AND rebase there are two ways to do this:
1. Hit Rebase Button on the gerrit change page then git checkout, make
change, git commit --amend, git review.
- The problem with this is that it creates two patch sets.
2. git checkout the gerrit change that your gerrit change is dependent
on.  Then cherry-pick your gerrit change on top of that.  This is
essentially a rebase, and now you can make changes to the code, commit
--amend and git review.  Gerrit will only see this commit hash changed
once, so only one patch set.

One other thing to keep in mind is since your change is dependent on
others you have to rely on your change's dependents to be rebased with
master.  You shouldn't do a rebase against master until the change you
are dependent on has been merged.  So the only time you should rebase is
when gerrit shows the OUTDATED message on your dependency.

Hope that helps explain my methodology, which is still a work in
progress.  However, I think this is a decent methodology when dealing
with a massive dependency chain like this.

Thanks,
Brandon


On Tue, 2014-07-29 at 16:05 +0000, Doug Wiegley wrote:
> Hi Evgeny,
> 
> 
> I’m not sure I’m doing it in the most efficient way, so I’d love to
> hear pointers, but what I’ve been doing:
> 
> 
> First, to setup the dependent commit, the command is “git review –d”.
> I’ve been using this
> guide: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependency
> 
> 
> Second, when the dependent review changes, there is a ‘rebase’ button
> on gerrit that’ll get things back in sync automatically.
> 
> 
> Third, if you need to change your code after rebasing from gerrit,
> this is the only sequence I’ve tried that doesn’t result in something
> weird (rebasing overwrites the dependent commits, silently, so I’m
> clearly doing something wrong):
>      1. Re-clone vanilla neutron
>      2. Cd into new clone, setup for gerrit review
>      3. Redo dependent commit setup
>      4. Create your topic branch
>      5. Cherry-pick your commit from gerrit into your new topic branch
>      6. Use "git log -n5 --decorate --pretty=oneline”, and verify that
>         your dependency commit hashes match what’s in gerrit.
>      7. Git review
> 
> 
> Thanks,
> doug
> 
> 
> 
> 
> From: Evgeny Fedoruk <EvgenyF at Radware.com>
> Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> Date: Tuesday, July 29, 2014 at 7:12 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Neutron] Managing change in gerrit which
> depends on multiple other changes in review
> 
> 
> 
> Hi folks,
> 
>  
> 
> I’m working on a change for neutron LBaaS service.
> 
> Since there is a massive work done for LBaaS these days, my change
> depends on other changes being reviewed in parallel in gerrit.
> 
> I don’t have a big git knowledge and I’m failing in figuring out the
> right procedure that should be followed for managing such a
> multi-dependent patch.
> 
> So, I sending my question to you guys, in hope to find the right way
> to manage such patches in gerrit.
> 
>  
> 
> Here is the situation:
> 
> There are 4 patches on review in gerrit
> 
> 1.      A – No dependencies
> 
> 2.      B – Depends on A
> 
> 3.      C – Depends on A
> 
> 4.      D – No dependencies
> 
>  
> 
>  
> 
> My change, let’s call it “X”, is already on review in gerrit.
> 
> It should depend on all four other changes, A, B, C and D.
> 
>  
> 
> I tried to two ways of managing those dependencies, 1) by doing a
> cherry-pick for each one of them, and 2) by doing git review and git
> rebase for each one of them.
> 
> It does not work for me well, my change commit message is replaced by
> other changes’ commit messages and when I commit my patch, it commit’s
> other changes patches too.
> 
>  
> 
> So, my question is: 
> 
> Is this scenario supported by gerrit system?
> 
> If it does – what is the right procedure to follow in order to manage
> those dependencies
> 
> and how to rebase my change when some of dependencies was commited
> with a new patch to keep the dependencies up-to-date?
> 
>  
> 
>  
> 
> Thank you!
> 
> Evg
> 
>  
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev