4

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?

Community
  • 1
  • 1
trejder
  • 17,148
  • 27
  • 124
  • 216

2 Answers2

3

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.

Magnus Bäck
  • 11,381
  • 3
  • 47
  • 59
  • So, you say, that I can create as many local branches as I want, but always push using `refs/for/master` and always push only master branch, and don't create any remote branches? But, if I'll do that, I'll suffer problem of dependencies and I'll have [a whole lot troubles, when abandoning a change](http://stackoverflow.com/q/20496959/1469208). I was told, that using branches solves this problem, because abandoned change from one branch doesn't affect change from other branch. How is this going with your statemented here? The question of life is: to branch in Gerrit or not to branch? :] – trejder Dec 17 '13 at 09:10
  • 1
    If you start a new _topic branch_ for each independent change you won't end up with any intercommit dependencies. If you think about it, when you push one or more commits for review you _are_ essentially branching the repository. It's just that your branch is implicit, short-lived, and not useful to attach a name to. – Magnus Bäck Dec 17 '13 at 14:06
  • And even if I'll go with each topic branch per each change, I still have to push only `master` branch (with `--all` parameter?) and always with `refs/for/master`? Am I getting these things right? – trejder Dec 17 '13 at 14:30
  • 1
    Why would you use the `--all` option? Since one normally pushes the currently checked out branch, `git push origin HEAD:refs/for/master` is a good pattern. – Magnus Bäck Dec 17 '13 at 14:38
  • I still don't get it! I did exactly, like you told me: create local branch (but no corresponding remote branch), commit changes, push it to Gerrit, to master (`git push origin HEAD:refs/for/master`), review in Gerrit, pull everything, delete local branch. And now all is fine (I even get everything merged to master after final `git pull`, after review). Except, that still all my changes have set `Depends On` and `Needed By` to "surrounding" changes. So, if I abandon one, I'll end up with the same mess, I tried to avoid by creating remote branches (which you told me to not to do). – trejder Dec 20 '13 at 09:35
  • So: how to make Gerrit have every change I push completely separate, without `Depends On` and `Needed By` set to anything, so I can abandon any change without worries for annoying, irritating message, "[Change could not be merged because of a missing dependency. The following changes must also be submitted](http://stackoverflow.com/q/20496959/1469208)"? – trejder Dec 20 '13 at 09:38
  • Exactly how are you creating your local branch? Is it based on origin/master? What's the output of `git rev-list origin/master..A`, where A is the SHA-1 of a commit where Gerrit claims there is a dependency? – Magnus Bäck Dec 20 '13 at 13:56
1
  • 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
laplasz
  • 3,359
  • 1
  • 29
  • 40
  • Let me check this. By "_submit the change to remote branch_" you mean reviewing the change in UI and submitting it (so Gerrit will "merge" it, whatever that means to it)? – trejder Dec 16 '13 at 11:59
  • yes, that what I mean - it will merge the chage to the corresponding remote branch - not to remote master – laplasz Dec 16 '13 at 12:09