Branch/change not merged, though Gerrit claims, it is

Question

Each time, I see merged status on my change in Gerrit and I do git pull origin, I can clearly see, that my change/branch hasn't actually been merged into master.

Please, review my Gerrit's workflow and tell me, what I'm doing wrong or what am I missing:

1. Create & checkout branch locally.

   git checkout -b 77-blah

2. Do the magic and comment all changes.

   git commit -am "changes to 77-blah"

3. Create the same branch using UI and setting its revision to HEAD (this should be automated soon).

4. Push changes (that particular branch) to Gerrit, with proper refs refs:

   git checkout 77-blah

   git push origin HEAD:refs/for/77-blah

5. Visit URL, Gerrit gave me, review my change or wait for someone else to review it.

6. Visit change's URL again, make sure that Status = Merged.

7. Pull latest changes from Gerrit:

   git checkout master

   git pull origin

Last command's result ends with Already up-to-date, which (if I'm not stupid) means, that my master is up-to-date. In normal Git's repo, at this point, this would be true. My master branch would become up-to-date, with my latest (77-blah) branch already merged to it.

On Gerrit I'm refreshing my webpage, that I'm currently working in (while I'm on master) only to find out, that all changes introduced in that particular branch are gone and the entire website is in state before creating latest branch. Gerrit only claims, that my master is up to date.

And I can confirm that, by executing git branch -d 77-blah and getting as the result:

error: The branch '77-blah' is not fully merged.
If you are sure you want to delete it, run 'git branch -D 77-blah'.

Actually, I have to merge my latest branch manually locally. What am I missing?

What does it mean (in Gerrit terms) that change is merged, while it actually isn't merged at all?

Answer 1

A common theme in your couple of similar questions seems to be that you think you should push your local topic branch to a branch with the same name in Gerrit, and that submitting the change (i.e. making the change show up as Merged) means that Gerrit should merge the change to master. This is incorrect.

When you push to refs/for/whatever and later submit that change, the commit ends up on the branch whatever. Not master. If you want the change to end up in master you should push to refs/for/master. So, Git's claim that master is up to date is correct (that branch is unaffected by your submission of a change to 77-blah) and Gerrit's claim that your change has been merged is also correct (the change was merged to 77-blah).

Local topic branches are unrelated to the branches maintained on the server. It's unusual and rarely desirable to have a 1:1 relationship between them. In fact, creating branches on the Gerrit server (i.e. having the Push permission for refs/heads/*) is usually a privileged action that most users can't perform. What they can do is push to refs/for/* to upload their changes for review. Locally they can course create any branches they want.

Answer 2

• create a local branch: git checkout -b 77-blah origin/master
• create the remote branch as well: git push origin 77-blah or via Gerrit UI.
• do the magic, commit it.
• make sure that the local branch is up to date - git pull (i recommend git pull --rebase)
• push the change - git push origin 77-blah:refs/for77-blah
• submit the change to remote branch
• merge the change to master branch from 77-blah if you want, and that step was incorrect at your workflow - git checkout master and use git pull to update all the local branches instead of git pull origin since this will be resolved by git as git pull origin/master where there is no new change yet. so merge the 77-blah to master - git merge origin/77-blah
• push the change directly to remote master git push origin master