Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is git push gerrit HEAD:refs/for/master used instead of git push origin master

Tags:

git

gerrit

People also ask

What is the difference between git push and git push origin master?

Git Push Origin vs Git Push Origin MasterGit Push Origin pushes all the branches to the main branch. Git Push Origin Master pushes your master branch to the origin. Behavior could be changed via git config.

Why is git push origin master not working?

If git push origin master not working , all you need to do is edit that file with your favourite editor and change the URL = setting to your new location. Assuming the new repository is correctly set up and you have your URL right, you'll easily be able to push and pull to and from your new remote location.

What are refs Gerrit?

The refs/for/ prefix is used to map the Gerrit concept of "Pushing for Review" to the git protocol. For the git client it looks like every push goes to the same branch, e.g. refs/for/master but in fact for each commit that is pushed to this ref Gerrit creates a new branch under the refs/changes/ namespace.

What is head Gerrit?

git push origin HEAD:refs/for/master. The refs/for/[BRANCH_NAME] syntax allows Gerrit to differentiate between commits that are pushed for review and commits that are pushed directly into the repository. Gerrit supports using either the full name or the short name for a branch.


The documentation for Gerrit, in particular the "Push changes" section, explains that you push to the "magical refs/for/'branch' ref using any Git client tool".

The following image is taken from the Intro to Gerrit. When you push to Gerrit, you do git push gerrit HEAD:refs/for/<BRANCH>. This pushes your changes to the staging area (in the diagram, "Pending Changes"). Gerrit doesn't actually have a branch called <BRANCH>; it lies to the git client.

Internally, Gerrit has its own implementation for the Git and SSH stacks. This allows it to provide the "magical" refs/for/<BRANCH> refs.

When a push request is received to create a ref in one of these namespaces Gerrit performs its own logic to update the database, and then lies to the client about the result of the operation. A successful result causes the client to believe that Gerrit has created the ref, but in reality Gerrit hasn’t created the ref at all. [Link - Gerrit, "Gritty Details"].

The Gerrit workflow

After a successful patch (i.e, the patch has been pushed to Gerrit, [putting it into the "Pending Changes" staging area], reviewed, and the review has passed), Gerrit pushes the change from the "Pending Changes" into the "Authoritative Repository", calculating which branch to push it into based on the magic it did when you pushed to refs/for/<BRANCH>. This way, successfully reviewed patches can be pulled directly from the correct branches of the Authoritative Repository.


In order to avoid having to fully specify the git push command you could alternatively modify your git config file:

[remote "gerrit"]
    url = https://your.gerrit.repo:44444/repo
    fetch = +refs/heads/master:refs/remotes/origin/master
    push = refs/heads/master:refs/for/master

Now you can simply:

git fetch gerrit
git push gerrit

This is according to Gerrit