Gerrit/resolve conflict

Gerrit random questions for now.

My change had a "path conflict", how do I rebase / merge it?
For the impatient:

 git-review -d  git rebase gerrit/master git status  git add git rebase --continue git review

The full explanation follow below.



So you have submitted a change and was approved. But by the time it gets reviewed other commits have altered the main repository which now cause a conflict. Gerrit is unable to automatically merge your change into the repository, you will have to fix it and resubmit the change.

The example below is based on a real use case : change 2514 using the operations/puppet repository

First fetch the change using git-review and its -d option :

(production)$ git-review -d 2514 Downloading refs/changes/14/2514/1 from gerrit into review/hashar/ignore_pyc Switched to branch 'review/hashar/ignore_pyc' (review/hashar/ignore_pyc)$

hashar is the user name, ignore_pyc the topic name he gave. Notice how git-review automatically placed you to the branch.

You now have to rebase on top of the main branch. The change on gerrit shows the branch, just add "gerrit/" in front. For this change in the operations/puppet repo, the main branch is "production", so rebase on gerrit/production.

(review/hashar/ignore_pyc)$ git rebase gerrit/production First, rewinding head to replay your work on top of it... Applying: pyc files are now ignored Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging .gitignore CONFLICT (content): Merge conflict in .gitignore Failed to merge in the changes. Patch failed at 0001 pyc files are now ignored When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". (no branch)$

The key in the above output is the line starting with CONFLICT. It tells you the filename that git couldn't cleanly rebase, usually because your patch alters it and changes in the main branch have also altered it. Running git status confirms it:

(no branch)$ git status (no branch)$
 * 1) Not currently on any branch.
 * 2) Unmerged paths:
 * 3)   (use "git reset HEAD ..." to unstage)
 * 4)   (use "git add/rm ..." as appropriate to mark resolution)
 * 5) 	both modified:     .gitignore
 * 1) 	both modified:     .gitignore

Edit the conflicting file (in this case .gitignore).

Once you have finished editing, you have to add that modification to have it used during the rebase then continue fixing any conflicting patches:

(no branch)$ git add .gitignore (no branch)$ git rebase --continue Applying: pyc files are now ignored (review/hashar/ignore_pyc)$

Since there was no more patches to fix, you have been placed back in the review/hashar/ignore_pyc branch. Looking at the log:

$ git log -n5 --decorate --pretty=oneline ...
 * a3631d2 (HEAD, review/hashar/ignore_pyc) pyc files are now ignored (2 seconds ago
 * 1b6cd67 (gerrit/production, production) ensure sample config file removed (18 hours ago)

Verify you change looks fine before resubmitting it to gerrit. Just use git show, i.e. git show a3631d2. You can eventually amend it to state you have rebased the change.

Now submit your change back in the repository:

(review/hashar/ignore_pyc)$ git review remote: Resolving deltas:  0% (0/2) To ssh:// @gerrit.wikimedia.org:29418/operations/puppet.git (review/hashar/ignore_pyc)$

Heading back to Gerrit, the change is a new patchset pending review:



Congratulations on fixing your first rebase / merge conflict!

git review warns about submitting other people's commits
Sometimes when running git review, you get a warning saying you're about to submit multiple commits, followed by a list of other people's commits that have already been merged.

If this happens, the workaround is This will ensure git-review has an up-to-date view of the remote master.
 * 1) respond "no" to abort git-review.
 * 2) run git fetch gerrit
 * 3) rerun git-review

Background
Roan fixed this in 2012 in https://review.openstack.org/#/c/6741/ , the bug returned in the latest release of git-review that came out in April. Change https://review.openstack.org/#/c/20450/ reintroduced the broken behavior. WMF projects suffer from this disproportionately because we have defaultrebase=0 set on most of our projects, and the bug only triggers when rebasing is disabled (using either that setting or the -R flag).