How to make a branch review with Gerrit
Asked Answered
L

2

1

How can I do a branch review with gerrit? I want to analyse all branch changes in one gerrit change.

The idea is to review the code of a branch with multiple changes (commits).

Land answered 16/1, 2019 at 15:49 Comment(2)
Maybe this will help : mediawiki.org/wiki/Gerrit/TutorialTsarevitch
The review will be commit-base and not branch-based, the option is to do a squash before commit. I'm looking something similar to gitlab merge approvals.Land
H
0

If you want to review a branch with multiple commits Gerrit isn't an appropriate tool for that. Reviews in Gerrit are performed in every commit individually. Github or Bitbucket are tools suitable for branch review.

Answered your question, a suggestion: IMHO you should try to work with Gerrit, reviewing every commit individually, because it's a very nice workflow. I really like (and prefer) Gerrit strategy.

Hendry answered 16/1, 2019 at 17:8 Comment(1)
Thank you Marcelo. Right now we are using gitflow, so we prefer a feature review instead a commit review.Land
F
0

I created a git alias which facilitates the traditional git workflow (with multiple commits on a "working" branch) along with pushing them to Gerrit automatically with the same Change-Id in the commit message. It can be added to .gitconfig file:

...
[alias]
    gerrit = "!git reset --soft $(git rev-list master..HEAD | tail -1) &&  \
               git commit --amend --no-edit &&                             \
              (git push origin HEAD:refs/for/master; git reset HEAD@{2})"

Assumption:

  • you have created a branch for your topic/fix change and placed at least one commit;

Usage: git gerrit


This works as follows:

git reset --soft $(git rev-list master..HEAD | tail -1)

git rev-list master..HEAD | tail -1 obtains SHA-1 of the first commit we created on the branch (after forking from master), I will call it the "base" commit. Then we feed this SHA-1 to: git reset --soft which moves the branch pointer back to this commit turning all changes from later commits into staged. Then:

git commit --amend --no-edit

we squash staged changes into the base commit with a single --amend. The original commit message will be preserved and so will be Change-Id.

git push origin HEAD:refs/for/master

This is the point of everything - we push to Gerrit...

git reset HEAD@{2}

and finally we restore the original shape of our branch utilizing reflog history, HEAD@{2} means a revision where our HEAD was two steps ago (before commit --amend and first reset).

Advantages:

  • you maintain your own granularity of commits on the working branch, you can edit them with git rebase -i as much as you like for logical order and readability (don't modify Change-Id from the "base" commit message);
  • at the same time with a single command you upload newest changes to Gerrit making it accept them as another patchset of the same Change without SPAMMING your Change List with multiple related Changes.
Fonseca answered 14/1, 2021 at 18:22 Comment(1)
Thanks, its a good strategy. We end up choosing gitlab instead gerrit.Land

© 2022 - 2024 — McMap. All rights reserved.