How do I work in multiple fixes while waiting for a review in Gerrit?

Question

I've been looking around the web, and can't find the exact answer.

I've been using git under the git flow model for a couple of years now. I switched jobs recently, and here, we use Gerrit.

With Gerrit, among other restrictions, I don't seem to find the proper way to work on 2 separate fixes/features and review them at the same time. As I understand, I have to be working on top of the master branch, and can only push 1 commit at a time (unless I patch my initial review). Which is very different to what git is for me.

In git I could just do:

# work in a feature
git checkout -b feature/awesome
echo "nice" > nice.txt
git add nice.txt
git commit -m "My nice change"
git push -u origin feature/awesome

# work on a hotfix
git checkout -b hotfix/1.1.1
echo "fixed" > fixed.txt
git add fixed.txt
git commit -m "It's fixed"
git push -u origin hotfix/1.1.1

Then 2 guys would be reviewing my code before it would get merged into master or develop branches and properly tagged.

I know I just need to learn this new Gerrit model, but could someone help me figuring out how to work in 2 different reviews at once? I feel my productivity just got dropped to 20%.

Answer 1

I'm only a gerrit user, not an admin, so maybe I'm off-base here, but why can't you have several open changes in gerrit at the same time? I have four open changes in the same project right at this moment.

I don't keep local branches. In fact, there's rarely anything important in my working tree when I go home at night.

When I want to start a new change:

git reset --hard
git fetch
git checkout master
git reset --hard origin/master

# make my changes

git add ...
git commit
git push origin HEAD:refs/publish/master

When I want to work on some other change that's already in gerrit:

git reset --hard
git fetch ssh://[email protected]/project refs/changes/nn/nnnnn/pp
git checkout FETCH_HEAD

# make my changes

git add ...
git commit
git push origin HEAD:refs/publish/master

Those reset --hard lines are seldom a problem because, like I said, I don't keep anything important in my local working tree.

The only trick is, if I've got two or more open changes that touch the same file, I may have to do a manual git merge to sort them out. That's no worse than if I and some other developer tried to change the same file at the same time.