This is getting to be an old thread, but the "magic" for adding multiple
changes is as follows:

* use your working branch
* make changes
* git commit -a --amend
* save...
* git review

This way, the same branch, with the initial commit, will be preserved along
with the same change ID.

If you want to build upon an initial review, then you can do:

* git checkout -b intial_changes
* ...make changes and git review...
* git checkout -b secondary_changes
* ...make changes, git commit, git review...

This will provide a second review, based upon the first one.

If you need to change the first review, then that's fine. Follow the
initial procedure with making changes, and then git commit -a --amend,
along with git review.

If upstream (master) changes, and you need to rebase, that's fine too.

* git checkout master
* git fetch upstream (assuming you've run a git remote add upstream <path
to upstream Asterisk master>)
* git rebase upstream/master
* git review

Then if you need to rebase the secondary patch, after rebasing your
initial_changes branch, just rebase against origin/initial_changes, and run
your git review again.

This way, you can chain changes, and not have to duplicate work. As the
reviews happen and you make changes, you just keep committing against the
same change ID (which happens when you git commit -a --amend; git review),
and eventually things get merged down from the initial branch to your
secondary, tertiary, etc branches.

Hope that helps. Let me know if you need any additional help...


On Tue, Aug 23, 2016 at 5:45 AM, Joshua Colp <> wrote:

> Dennis Guse wrote:
>> Hey,
>> we adjusted the patch set (fftw3 is now a ifdef-ed).
>> Precisely, these two commits have been modified (basically adding
>> Two questions:
>> 1. It seems that we were working outside the commit tree by adjusting
>> 3522 and 3524 - we pulled each one down using _git review -d XXXX_,
>> applied the modifications, and submitted using _git review_
>> Is it necessary to also "re-commit" the subsequent patches (or does
>> gerrit this automatically)?
>> And if so, how?
>> At the moment Gerrit does not try to rebuild the subsequent patches
>> (i.e., 3523 and 3525).
> Gerrit does not automatically do this, it's up to you to rebase the
> patches so that a review is rebased on the latest version of the one it is
> dependent on. You can either do this from the web interface using the
> Rebase button (if it will cleanly rebase) or you have to build up a patch
> series on your system. This can be done by creating a local branch and
> pulling down each patch into it using (git review -x <review>), making any
> changes needed, committing, and doing git review again. This provides the
> dependency information to Gerrit it needs.
> 2. How can we withdraw the OPUS patch from the patch set?
> You can click "Abandon" from the web interface and it will abandon that
> specific review.
> Cheers,
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: &
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by --
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:

Leif Madsen
-- Bandwidth and Colocation Provided by --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to