Talk:Gerrit/Advanced usage
For archived talk, see Talk:Git/Workflow/archive
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Permission denied (publickey) | 5 | 09:07, 22 May 2013 |
| In fact, what about getting rid of this page? | 2 | 19:34, 1 March 2013 |
| Merging How we review with | 0 | 15:43, 28 February 2013 |
| Removing Git installation instructions from Workflow | 0 | 15:39, 28 February 2013 |
| Gerrit for MediaWiki core and extensions or anything? | 0 | 15:18, 28 February 2013 |
| Inline comments | 3 | 14:58, 22 February 2013 |
| Git setup on Windows a nightmare | 3 | 23:34, 1 February 2013 |
| Section I removed | 1 | 18:47, 3 January 2013 |
| Release notes conflicts | 3 | 00:36, 5 December 2012 |
| git review broken when cloning using review | 3 | 21:27, 4 December 2012 |
| Bugzilla | 10 | 22:06, 8 November 2012 |
| Helpful script, switch between branches with intermediate rebase | 0 | 21:54, 6 August 2012 |
| Better commit messages | 4 | 14:32, 31 July 2012 |
| Windows/git push-for-review and creating amendments for a patch-set | 4 | 05:00, 8 July 2012 |
| [remote rejected] ("branch not found") | 3 | 13:31, 14 June 2012 |
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?
Aha! Glad you figured it out.
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
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.
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.
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.
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.
Heiya, just a tiny question: In case I comment on code inline or reply to comments inline I cannot save it properly, just as a draft which causes it not to show up for others. I am probably doing something wrong, but I do not know what it is? Cheers
It's another of Gerrit's unintuitive parts. You have to click the "review" button back in the change overview page, and the draft inline comments will be attached to your "global" comment when you save it.
This definitely is not a way to go... I spent whole afternoon trying to contribute a single line of code but failed to set the whole thing up... :-( I dont know thether Subversion was easier, but this definitely is not a way how to attract more developers...
If you have any problems setting up Git or submitting code, come to IRC to get direct chat support. Most developers hang out there and will help you with any problems.
Well unless you have a specific problem then there's nothing anybody can do to help. I don't think this difficult to install on Linux so it can't be preventing more developers from joining.
S has added complicated instructions about gerrit/origin.
We are dozens of people to not have any problem. I temporarily removed these confusing instructions, and would like opinion from Git and Gerrit experts.
Here the text:
Using a "gerrit" remote consistently [edit]
Before starting with git-review you should double-check how git refers to repositories. When you clone a repository, by default git gives the remote repository the nickname origin (unless you override this with -o gerrit as the sample commands on this page do), thus most git how-tos on the web use "origin". But the git-review tool prefers to use a remote called gerrit. If you're pulling code from gerrit.wikimedia.org then "origin" and "gerrit" are equivalent, yet if you fetch or pull from one but log/show/commit to the other you'll get different results!
Here's how to fix it:
- Double check the git remotes (nicknames) available
git remote -v
If it shows something like
origin ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (fetch) origin ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (push)
then follow these steps.
- Rename "origin" to "gerrit"
git remote rename origin gerrit
If you already try git-review, the above won't work since you will probably have "gerrit" remote already. So just remove origin:
git remote rm origin
- Change the tracking branch for "git pull"
In order for "git fetch" and "git pull" to show a helpful
Your branch is behind 'gerrit/master' by 63 commits, and can be fast-forwarded.
, you need to tell your local branch (for example "master") to track "gerrit/master" instead of "origin/master":
git branch --set-upstream master gerrit/master
After this you don't need "origin" anymore and you can safely use shortcuts like "git pull" to update your working copy.
Unfortunately you must perform these steps for every project checked out, i.e. core and extensions.
- Checking if everything is OK
After changes the configuration should look like:
git remote -v gerrit ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (fetch) gerrit ssh://username@gerrit.wikimedia.org:29418/mediawiki/core.git (push) git branch -vv *master abad0ee [gerrit/master: behind 53] Some comment
Should we let this section removed or should I add it again?
There's been a little discussion on the problem of release notes in wikitech-l.[1] For a newbie non-coder like me, release notes conflicts are quite a nightmare, but I heard more experience coders complaining about rebase failures as well: is this one of the reasons why our release notes are so lacking?
Should the docs say something about e.g. adding release notes only with last patchsets, or with follow-up commits, or in batches? I think I'll never submit multiple i18n commits at once each modifying the same section of the release notes; I'll either add the release notes later or wait for each commit to be merged before adding the next, hoping for things to be less painful.
Merge conflicts shouldn't be a nightmare; at most they are a nuisance :-). I don't think that there should be "last patchsets" or follow-up commits: A commit should encompass one complete change, from code to tests to documentation, in every patchset. If you have changes that depend on each other (apart from the release notes), they should be submitted as such.
For more advanced use cases, there are merge drivers for example for GNU-style Changelogs that could inspire a similar tool for MediaWiki release notes. But I don't know how that integrates with Gerrit/Jenkins and if merge conflicts in release notes are really that much of a burden to MediaWiki developers.
To clarify: they're a nightmare, and not a simple nuisance, because by the time someone with +2 arrives to approve the rebased change a new conflict is likely to arise, and so on unless you're wise enough to be on IRC and rebase if only if there's a willing +2'er available.
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://mattflaschen@gerrit.wikimedia.org:29418/mediawiki/extensions/EventLogging.git
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
Hostname gerrit.wikimedia.org
Port 29418
User mattflaschen
Am I missing something, or are these instructions wrong? Does anyone know the specific cause?
As you can see when I spelled it out, I switched the repo. I'm in the process of retesting properly.
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.
It's git-review bug 912125. It does not understand SSH shortcuts and insists on "username@full.host.name:port" 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)
and
git push gerrit HEAD:refs/for/master
or
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.
The page lacks instructions about what to do with bugzilla. The only relevant passages are:
- If your commit addresses a bug in Bugzilla, please comment on that bug to note that the commit is in the merge queue, and link to its changeset in Gerrit.
- If you merge a commit that references a Bugzilla bug, please go to that bug and mark it RESOLVED: FIXED and reference the merge ID.
How to become a MediaWiki hacker#Pushing for review through Gerrit says:
- Post a link to your Gerrit changeset in the appropriate bug report in Bugzilla with gerrit <changenumber>, and mark it with the patch and patch-need-review keywords.
I don't think it makes sense to have the code review queue for open commits on two separate tools?
What we're seeing is that most people mark the bug as fixed as soon as they commit the fix (otherwise they forget to), the dev who merges definitely marks as resolved fixed (although sometimes they forget) and then when further tested should be marked as verified fixed (by the reporter) or reopened. It's very confusing what one is actually supposed to do though.
We don't have currently a CLOSED state; which is supposed to say "fix made it into the release / and got deployed".
Sometimes we consider things FIXED once they are deployed on Wikimedia; sometimes it's when they go into the release.
I'd propose RESOLVED+FIXED to be done on merge, so that the requestor can make it VERIFIED FIXED using trunk.
We should decide whether CLOSED is "went into the release" or "got deployed" and when.
- Push a commit that fixes a ticket (or rather, claims to fix - since it is not reviewed yet).
- Should mention the ticket ID in the commit-msg ("(bug 0000) Did foo and bar, made quux work again").
- Comment on the ticket saying a proposed patch for this bug has been pushed to the review queue (mention gerrit change-id number or hash. Hash is probably better since numbering is less stable).
- A fix is reviewed/merged into the repo
- Mark related tickets as resolved/fixed.
Optionally:
- Somebody using master verified that it works for him. This includes testing on a live Wikimedia project after deployment (since we deploy from master now - be it in a temporary branch, but those are always based on the latest master at that time). The user may mark it VERIFIED?
What the meaning of CLOSED isn't really relevant, since we don't use it and don't have it enabled.
- Pushing a commit with a proposed fix should change the bug status to fix released. We don't have any equivalent to this status in bugzilla, creating this status would be useful. I'd suggest adding the keyword "patch-in-gerrit" for bugs in the review queue.
- A fix is reviewed/merged into the repo - this should change bug status to fix-committed. We don't have any equivalent to this status in bugzilla. I'd suggest changing the resolved/fixed status to resolved/committed, and move the keyword.
- The reporter or anyone who tested it and saw it's working can set the status to resolved/verified.
I think that the dev who merges should change the status of the bug after merging.
| “ | Pushing a commit with a proposed fix should change the bug status to fix released. We don't have any equivalent to this status in bugzilla, creating this status would be useful. I'd suggest adding the keyword "patch-in-gerrit" for bugs in the review queue. | ” |
+1. status for "there exists a fix in gerrit that will probably get reviewed" would be useful
Note that Mer Project's Bugzilla has a workflow with an additional step that might help clarifying things: RESOLVED FIXED (patch merged/committed to codebase) -> RELEASED (fix included in tarball) -> VERIFIED (reporter checked that commit actually fixed the issue). Bugzilla4 allows custom workflows in its settings. I agree that the Gerrit commit link should be more advertised. Adding "gerrit <changenumber>" currently is not too helpful as that is not even automatically turned into a direct link (compared to "bug <bugid>").
The instructions "Post a link to your Gerrit changeset in the appropriate bug report in Bugzilla with gerrit <changenumber>, and mark it with the patch and patch-need-review keywords" contradicts the actual behavior that I see in Bugzilla (people asking to remove the "patch-need-review" keyword after a patch has been sent to Gerrit for review). Definitely needs fixing plus clarification on https://bugzilla.wikimedia.org/describekeywords.cgi
I wrote this to help switch between branches, I call it "git-scuttle". Check it out:
#!/bin/bash git stash git checkout master git pull --rebase origin master if [ $# -ge 1 ]; then git checkout -b $1 || git checkout $1 fi
Put this in a file named "git-scuttle", make it executable, and put it in your path. Then, simply running
$ git scuttle
will bring you back to master with no pending changes (and anything you forgot will be stashed safely). If you want to switch to a different branch,
$ git scuttle new-branch
will bring you there (and create it if it doesn't exist).
See this, it looks odd. The commit-msg hook could check if the message-summary was too long and abort. I am not well enough with shell scripts
I'm not sure I see the problem? Also, the commit-msg hook is maintained upstream--it's not something we wrote.
The parent has changed so you don't see it; still visible at https://gerrit.wikimedia.org/r/#/c/17007/.
Ah. Well the commit-msg hook is still maintained upstream. Also, I think the UI's been fixed in 2.5 to truncate these sorts of super-long commit msgs.
Ok, great.
We are using Windows and git push-for-review and as windows user we have to use the manual for git push-for-review procedure since the installation of phython is an absolute no-go and since the workflow is not clear about how to use git push-for-review in combination with a amendments on patch-set, we'd really like know how this should work.
First branching, now patch sets ...
"git-review -R" is more or less the same as "git push remote HEAD:refs/for/branch", like "git push gerrit HEAD:refs/for/master".
"git-review -d" can be replaced with the "git fetch ...." command given in the Gerrit user interface to fetch the change.
Do you have some more specific issue with using git commands?
Topic branches
Doing the 1-0-1 routine of
- git checkout -b bug/123 master
- ...
- git commit
Later when using git push-for-review the commit goes always against the master and never creates a topic bug/123 but I'd expected local branch bug/123 would go automatically into gerrit as topic but it doesn't. So how Do I communicate using push-for-review that this commit (with local branch bug/123) belongs to the master with topic bug/123?
Ok, first - Gerrit "topic" have nothing to do with git branches. It's just an addition to the branch name specified on the command line. It's just an arbitrary text (you may write anything in your topic, no need to have branch or something like this).
So,
git push gerrit HEAD:refs/for/master/bug/123
will push your changes into "gerrit" remote (can be something else - check "git remote -v") and it says please push local HEAD (all commits until the most recent one here right now in this branch) on to "refs/for/master/bug/123" remote reference. Gerrit takes this reference "refs/for/master/bug/123" and interprets it this way: "it's meant for branch master, but please put it for review first and don't push directly" and then "the rest, i.e. bug/123 is a topic name".
If you have a fixed alias (git push-for-review) those parameters are pre-defined (probably to "git push gerrit HEAD:refs/for/master" only).
"git-review" does that for you - takes the local branch name and sets the topic to be the same. But that's only a kind of convention.
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".
