Talk:Gerrit/Advanced usage/Archive 2

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

Previous page history was archived for backup purposes at Talk:Gerrit/Advanced usage/LQT Archive 1 on 2015-07-10.

Hi, Sorry, but MW-Git and Gerrit are driving me crazy.

I wanted to push a patch into my own project "Semantic Web Browser" , but now I get the error:

benedikt@benedikt-ThinkPad-T410:~/Workspaces/Git-Repositories/SemanticWebBrowser$ git push 
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 1.24 KiB, done.
Total 8 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4)
remote: Branch refs/heads/master:
remote: You are not allowed to perform this operation.
remote: To push into this reference you need 'Push' rights.
remote: User: bkaempgen
remote: Please read the documentation and contact an administrator
remote: if you feel the configuration is incorrect
remote: Processing changes: refs: 1, done    
To ssh://bkaempgen@gerrit.wikimedia.org:29418/mediawiki/extensions/SemanticWebBrowser.git
 ! [remote rejected] master -> master (prohibited by Gerrit)
error: failed to push some refs to 'ssh://bkaempgen@gerrit.wikimedia.org:29418/mediawiki/extensions/SemanticWebBrowser.git'

Is it because someone (assumably a bot) created a branch in the project?

                Branch Name	Revision	
		HEAD	master	(gitblit)
		refs/meta/config	ad3f8c4f42a89287a45a796f4133c6787d579050	(gitblit)
		REL1_21	de4a45be3fb2c14b01c679c3ed006b77bcca254f	(gitblit)
		master	53c8a0ddabaf94fb72efce76167eba7cca71defb	(gitblit)

What do I need to do to be able to push, again?

Why is there the name gitblit in there? Are you sure you cloned from gerrit?

Hi Nemo,

Thanks for your answer.

Yes, I am pretty sure, I tried:

• git clone ssh://bkaempgen@gerrit.wikimedia.org:29418/mediawiki/extensions/SemanticWebBrowser
• git clone https://bkaempgen@gerrit.wikimedia.org/r/mediawiki/extensions/SemanticWebBrowser
• git clone https://git.wikimedia.org/git/mediawiki/extensions/SemanticWebBrowser.git

I now installed git review and were finally able to do "git review -R master", but now I have to review my own code in gerrit.

Is the MediaWiki repository still assumed to be used by ordinary extension developers? It has become quite complicated to manage your own extensions and I am not a noobie.

Best,

Benedikt

In other words, how can I do fast-forward or more easily push my changes?

I might need to stop using the repository, otherwise, since I just do not have the time to fiddle around with the system.

As it says in the error message (granted, the output is cluttered, this is an issue in Gerrit):

remote: You are not allowed to perform this operation.
remote: To push into this reference you need 'Push' rights.

Depending on how this particular repository is configured you are not supposed to push to the git repo directly. Instead you push for review to Gerrit and there Jenkins can run any lint/unit tests and perhaps code review and then it can be merged into the repository from the Gerrit interface (a bit like GitHub, except that everything is required to go via a pull-request, even if you end up merging it yourself).

If you are the owner of this repository you can request the right to push directly, thus bypassing Gerrit. Note though that you should not do this if you use Gerrit to process patches from other contributors since it'll be confusing if the Gerrit log doesn't show all commits. You can still merge your own commits if you so desire, just use git review (instead of git push) to submit to Gerrit and from there you can process them.

Dear Krinkle,

Thanks for the information. Nemo also helped me to review some patch. Apparently, I now can do fast-forward, I have just successfully pushed a new version of Semantic Web Browser to Git.

Best,

Benedikt

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? :)

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.

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.

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.

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.

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://mwjames@gerrit.wikimedia.org:29418/mediawiki/extensions/SemanticResultF
ormats.git
 ! [remote rejected] HEAD -> refs/for/bug37446 (branch bug37446 not found)
error: failed to push some refs to 'ssh://mwjames@gerrit.wikimedia.org:29418/med
iawiki/extensions/SemanticResultFormats.git'

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

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.)

There is no such remote branch for you to push to--see https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/SemanticResultFormats,branches

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.

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".

I hava no idea about that

The link http://docs.openstack.org/infra/zuul/gating.html#cross-repository-dependencies No longer exists. I can't find anything there that might be appropriate (didn't have much time to search).

Thanks for reporting this. Fixed in https://www.mediawiki.org/w/index.php?title=Gerrit%2FAdvanced_usage&type=revision&diff=2540616&oldid=2477577

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?

After seeing Git/Getting started, Git/Tutorial and Git/Code review/guide I see no point in keeping this page. Proposal: keep removing sections making sure that any useful content goes to the appropriate pages and then leave a redirect to Git/Getting started.

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

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.

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.

Git/Workflow#How_we_review_code is in fact not part of the workflow for submitting a contribution. We could just refer to Git/Code review/guide and make sure a nice intro is in place there.

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

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 https://help.github.com/articles/set-up-git . 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.

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.

kozuch@kozuch-VirtualBox:~$ git clone ssh://Kozuch@gerrit.wikimedia.org:29418/mediawiki/core.git
Cloning into core...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

kozuch@kozuch-VirtualBox:~$ ssh -vT kozuch@gerrit.wikimedia.org
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 gerrit.wikimedia.org [208.80.154.152] 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 'gerrit.wikimedia.org' 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_REQUEST sent
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?

resolved by deleting the passphrase :-(

Aha! Glad you figured it out.

This post was posted by Ori Livneh, but signed as Ori.livneh.

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.

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

I was breaking my head why this I couldn't login
untill I figuerd out that garret keys are diffrent from the wikitech keys
so you shouldn't add the keys in your wikitech settings
https://wikitech.wikimedia.org/wiki/Special:NovaKey

but instead you should use -
https://gerrit.wikimedia.org/r/#/settings/ssh-keys