20

Whenever I sent a review to Gerrit and if the review is pending for some time, I am getting cannot merge message in Gerrit.

I understood its coming because somebody else would have changed same file/files and delivered before me. I am trying below workaround to solve my issue.

  1. Abandon the current review.
  2. Create a new local branch, take a pull
  3. Cherry-pick my commit from old branch and send to gerrit

This works but the review comments whatever I had would no longer be available and it is difficult for my reviewer to check it again.

I am looking for a way to remove cannot merge from current review. Thanks!

Machavity
  • 30,841
  • 27
  • 92
  • 100
Bhargav Kumar R
  • 2,190
  • 3
  • 22
  • 38

3 Answers3

45

You do NOT need to abandon the current change on Gerrit to solve the "cannot merge" issue. All you need to do is:

  1. Update your local repository (git fetch)
  2. Run a manual rebase (git rebase)
  3. Resolve the conflicts (git mergetool, git rebase --continue)
  4. Commit (amend) the result (git commit --amend)
  5. Push a new patchset to Gerrit (git push)
5

Try rebase button, which can solve most cannot-merge issues. If it can find the proper commit to rebase onto by itself, it's okay. If it cannot, find the last commit of the target branch and fill in the commit blank. Sometimes you should first submit the commit, on which the cannot-merge one has dependency. If it cannot work anyhow, just abandon it and make the commit based on the latest commit.

ElpieKay
  • 27,194
  • 6
  • 32
  • 53
  • If simply clicking "Rebase" just work, then you just encontered this problem: https://bugs.chromium.org/p/gerrit/issues/detail?id=2734 " You could try enabling "Automatically resolve conflicts" in the settings to do a content merge instead. – user2707671 Jul 27 '18 at 08:14
1

The best practice when working on a shared code base using git/gerrit is to keep individual changes as small as possible. Instead of submitting your change in a single larger commit, split it into a series of smaller commits (submit the branch to gerrit) that have one logical change per commit. This workflow:

  • reduces the chance of conflict in a single change
  • makes conflicts easier and quicker to resolve
  • make the change quicker to review

This way, the chance that someone merges his changes before you lowers. You should rebase as soon as possible so that the changes can be reviewed more easily. Rebasing regularly against the upstream branch means you keep up-to-date with changes, and don't have to deal with a large merge conflict (you get smaller, more manageable issues to resolve).

I'm not sure this answers your question but I follow these two rules and have no problems.

elfie
  • 9
  • 3
Timotei
  • 78
  • 5
  • How can I keep changes to a minimum? – Bhargav Kumar R Jun 02 '16 at 07:02
  • 2
    For me keeping changes to minimum refers to not mixing refactoring code with new code, and splitting commits by scope, such as: refactor commit, implementation commit, testing commit (mostly for test coverage increase), Dependency upgrade commit and so on. Another thing is that I try to keep the commit as isolated as possible (just the functionality and tests) – Timotei Jun 02 '16 at 07:42