Talk:Gerrit/Advanced usage

Jump to navigation Jump to search

About this board

For archived talk, see Talk:Git/Workflow/archive

Cherry-picking multiple commits?

Samwilson (talkcontribs)

What's the correct process for adding a dozen or more commits from master to a release branch? Do they have to be done as individual patches? Or is it common to squash them? Or something else? Or should one just not let release branches get that far behind?Ā :)

Anomie (talkcontribs)

Release branches here don't normally have that much backported to them, mainly just security fixes and fixes for major bugs. When they do get backports, it's done by cherry-picking the individual patches.

I suppose it's possible some extension or the like follows a different model.

Samwilson (talkcontribs)

Ok, cool, good to know I'm not missing anything obvious.Ā :)

And yeah, it's mostly for extensions that I'm thinking ā€” where they're following a release branch policy, it seems like it's a good idea to ensure all commits are backported unless they're not compatible, because we recommend people checkout e.g. REL1_31 but they mightn't actually get any updates on that branch ever, and so are left further behind than they could be.

Krinkle (talkcontribs)

The benefit of cherry-picking is mostly that it integrates well with Gerrit. Specifically that 1) Clicking on or searching for the Change-Id reveals the change in all branches, 2) Using the "Included in" interface correctly shows the branches the change is a part of.

I'd expect cherry-picks for MediaWiki core. But individual extensions may do it differently if maintainers agree.

Samwilson (talkcontribs)

So the workflow could just be to merge a bunch of commits from master to REL1_31 locally, and then push all at once? But that requires particular permissions on Gerrit doesn't it? Normally, it'd just result in a separate patch being created for each commit, I think. I'm not sure how CI would work in that scenario anyway, because it'd still want to be testing each commit...

Sounds like the single-commit cherry-pick way is best, if a bit slower.

Reply to "Cherry-picking multiple commits?"

[remote rejected] ("branch not found")

MWJames (talkcontribs)

Doing a "git push-for-review" (we are working on windows meaning that this phyton script thing is a no/go, so instead using we are using the manual setup setting the alias before push to "git config alias.push-for-review "push origin HEAD:refs/for/bug37446") results in nothing more than:

remote: Resolving deltas: 100% (4/4)
To ssh://
 ! [remote rejected] HEAD -> refs/for/bug37446 (branch bug37446 not found)
error: failed to push some refs to 'ssh://

We create a branch bug37446, did the rebase, and checked that the SSH key is working (we are able to execute "ssh -p 29418").

The questions that are left what does this error mean and how do we resolve this? (Personally I use github for quite a while and I hadn't had any issues with git but this gerrit setup is somehow confusing.)

šŸ˜‚ (talkcontribs)
MWJames (talkcontribs)

Yes, I know that but than since I want to commit certain changes only to a branch, how do I create a branch? You can't expect people to commit patches (because the rational behind git was that "branching gets much easier") when you don't explain how to do create a branch.

Saper (talkcontribs)

With Gerrit this is a bit different story. Gerrit acts as a gatekeeper and only accepts commits into pre-defined git branches because it needs to know where an approved commit should be merged after a successful review. So forget about "branching gets much easier" part as far as Gerrit is concerned.

Gerrit project administrator can create Gerrit branches in the repository.

Please see the mailing list for more details: "Gerrit question: pushing to another branch". (talkcontribs)

I hava no idea about that

Reply to "[remote rejected] ("branch not found")"

Cross Project Dependencies has a broken link

DougBRobinson (talkcontribs)
AKlapper (WMF) (talkcontribs)
Reply to "Cross Project Dependencies has a broken link"

How to fix [OUTDATED] dependency on a patch

Phoenix303 (talkcontribs)

I am working on a patch that depends on another that's still under review.

  1. Patch A: parent patch still under review.
  2. Patch B: depends on A.

I have made new patchsets for A and on patch B's page, Gerrit shows that the dependency(patch A) is [OUTDATED].

Steps I have followed to fix this issue:

  1. Checked out patch A (git review -d 'patchA')
  2. Checked out existing patch B (git review -d 'patchB')
  3. git rebase review/user/patchA
  4. makes changes to a file
  5. git add 'files'
  6. git rebase --continue shows 'No rebase in progress?'
  7. git commit --amend
  8. git push gerrit HEAD:refs/for/master

git push throws error ' ! [remote rejected] HEAD -> refs/for/master (squash commits first)'.

How can I fix this?

Reply to "How to fix [OUTDATED] dependency on a patch"

In fact, what about getting rid of this page?

Qgil-WMF (talkcontribs)
Anomie (talkcontribs)

Remember that experienced users sometimes need a reference too, e.g. to look up the exact syntax for git push gerrit HEAD:refs/for/master. Having to dig through multiple random beginner-oriented pages to find this information would not be productive.

Qgil-WMF (talkcontribs)

Fair enough. I will continue removing the content for beginners e.g. Installing Git and linking to the Tutorial or other existing pages and let's see how far this goes.

This post was posted by Qgil-WMF, but signed as Qgil.

Reply to "In fact, what about getting rid of this page?"
Qgil-WMF (talkcontribs)
Reply to "Merging How we review with"

Removing Git installation instructions from Workflow

Qgil-WMF (talkcontribs)

In order to fix Bug 36437 - A strict and correct Git workflow document is needed one thing we can do is to remove from the Workflow document anything that is not strictly part of the workflow. I already removed the Justification section, and the Git installation instructions could follow. It is a one time action with no MediaWiki-specific steps and there are plenty of sites out there documenting very well how to do this.

Git/Getting started solves this step by simply linking to . Works for me, and if someone has a better URL we can just use it in addition or as replacement.

This post was posted by Qgil-WMF, but signed as Qgil.

Reply to "Removing Git installation instructions from Workflow"

Gerrit for MediaWiki core and extensions or anything?

Qgil-WMF (talkcontribs)

Our docs mention frequently that Gerrit code review is for MediaWiki core and extensions, but nowadays is more than that, isn't it? It would be better to say that we use Gerrit code review for anything. If there are exceptions (projects using GitHub only) then we can specify them somewhere.

Also, since we have everything mirrored in GitHub it would be nice to tell (especially to newcomers) what to do with that, and whether patches can be submitted that way.

This post was posted by Qgil-WMF, but signed as Qgil.

Reply to "Gerrit for MediaWiki core and extensions or anything?"
Kozuch (talkcontribs)
kozuch@kozuch-VirtualBox:~$ git clone ssh://
Cloning into core...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

kozuch@kozuch-VirtualBox:~$ ssh -vT
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file /home/kozuch/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/kozuch/.ssh/id_rsa-cert type -1
debug1: identity file /home/kozuch/.ssh/id_dsa type -1
debug1: identity file /home/kozuch/.ssh/id_dsa-cert type -1
debug1: identity file /home/kozuch/.ssh/id_ecdsa type -1
debug1: identity file /home/kozuch/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA b5:e9:dc:b2:dd:6e:70:f7:18:8a:dc:a3:5d:ab:99:4d
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in /home/kozuch/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/kozuch/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/kozuch/.ssh/id_dsa
debug1: Trying private key: /home/kozuch/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).

ssh-all -l is ok. PUB key copied to gerrit. Will someone help?

Kozuch (talkcontribs)

resolved by deleting the passphraseĀ :-(

ATDT (talkcontribs)
Krinkle (talkcontribs)

For your information, having passphrase on your key is not the problem. Many people have one (I'd even recommend it) and it works fine.

Nemo bis (talkcontribs)

On Windows? Looks like people are having a lot of trouble on Windows.

Yonjah (talkcontribs)
Reply to "Permission denied (publickey)"

git review broken when cloning using review

Mattflaschen (talkcontribs)

When I cloned using the review shortcut recommended here:

git clone -o gerrit ssh://review/mediawiki/extensions/Onboarding.git

the .git/config looked like:

[remote "gerrit"]
    fetch = +refs/heads/*:refs/remotes/gerrit/*
    url = ssh://review/mediawiki/extensions/Onboarding.git

which makes sense. However, git review failed with:

Problems encountered installing commit-msg hook
The following command failed with exit code 1
    "scp -P 22 review:hooks/commit-msg .git/hooks/commit-msg"
Permission denied (publickey).

until I changed it to:

url = ssh://

ssh review prints the standard "Welcome to Gerrit Code Review...Unfortunately, interactive shells are disabled." so I think the .ssh/config is correct. It's:

Host review
     Port 29418
     User mattflaschen

Am I missing something, or are these instructions wrong? Does anyone know the specific cause?

This post was posted by Mattflaschen, but signed as Superm401.

Mattflaschen (talkcontribs)

As you can see when I spelled it out, I switched the repo. I'm in the process of retesting properly.

This post was posted by Mattflaschen, but signed as Superm401.

Mattflaschen (talkcontribs)

Saper confirmed this issue. I was still able to do the setup with the correct spelled out repo, so it's not a repo-specific issue.

This post was posted by Mattflaschen, but signed as Superm401.

Saper (talkcontribs)

It's git-review bug 912125. It does not understand SSH shortcuts and insists on "" syntax.

Personally I prefer having an SSH shortcut and use

git fetch gerrit refs/changes/BB/AAAABB/PP 

to fetch a patchset (git-review -d)


git push gerrit HEAD:refs/for/master


git push gerrit HEAD:refs/changes/AAAABB

to push changes to gerrit (equivalent of git-review without parameters).

You can ofc have two remotes: I sometimes use "review" with SSH shortcut for the above commands and "gerrit" for git-review. YMMV.

Reply to "git review broken when cloning using review"