Talk:Git/Workflow/archive

Users already created?
The documentation says "Anyone who had a Subversion account already has a gerrit account" but I can't log in using my username (tbleher) and my MediaWiki.org password, even though I have an SVN account with extension access. Does anyone know if this already works (in principle) and how I could get access? Thanks! -- Tbleher (talk) 06:37, 16 February 2012 (UTC)
 * You don't use your mw.org password, you have to link your account to labs and get a password from that. The docs here need clarifying. ^demon (talk) 07:13, 16 February 2012 (UTC)

To add
Notes from my discussion with Chad earlier today. To add to this page or related pages.

STEP 1: before any of this, log in to labsconsole.wikimedia.org, verify that you can log in, then log in at gerrit.wikimedia.org and then click Settings and go to SSH Public Keys and paste in your id_rsa.pub (we aim to fix this soon by simply pulling the key from LDAP)

git clone ssh://sumanah@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples.git Cloning into examples... Permission denied (publickey). fatal: The remote end hung up unexpectedly issue: I'm not logged in to my ssh key right now. Solution: do ssh-add ~/.ssh/id_rsa to make it prompt me for the passphrase for my key, add to keychain to check, do ssh (has to be done this way - git pushes have to be over ssh, not over http or other unencrypted) then git clone ssh://sumanah@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples.git fingerprint - how to verify? dc:e9:68:7b:99:1b:27:d0:f9:fd:ce:6a:2e:bf:92:e1

check with ssh-add -l

cd examples/ to see what's in the repo now, trivial change. first with git manually, then with git-review <^demon> https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch for later: cleanup that page to indicate when to switch directories modified:  HelloWorld/HelloWorld.php usual git stuff -- like learning about git status, git diff, git commit -a -m git push-for-review should just push it to gerrit!

TODO: help people understand how to config their email settings in git and/or gerrit to make gerrit accept their changes remote: ERROR: committer email address (email) remote: ERROR: does not match your user account. Fix: add your secondary email in gerrit, click the conf link in the email to make gerrit accept it

look at changeset. 'gerrit2' is the autoreviewer. gerrit2 auto-verifies anything that passes the Jenkins tests. DOES NOT merge. verification is necessary but insufficient go to gerrit changeset. Look around. Note Abandon & Review buttons For reviewers: important things are Review button (overall comment) & Side-by-side diff, where you can double-click on a line and comment on that line! Then, click "Up to change" and the only way to see the inline code review comments is to click the Review button (it's not in the comments at the bottom of the changeset) OK, so now, to show me how it looks to do code review _and merge_, have the teacher add you to the project owner group <^demon> https://gerrit.wikimedia.org/r/#mine "Add reviewer" - manually ping someone to request their review. It'll show up in their gerrit stream as a review request So now, I see "Submit Patch Set 1". Don't click it! Click Review, click +2, add a comment, and hit Publish, or - to merge - click Publish And Submit and that will merge into the repo. In cases of merge conflicts, the code reviewer would have gotten a notice from gerrit that the merge couldn't go through, and the final merge step would fail, but all the code review would be untouched <^demon> sudo apt-get install python-pip <^demon> sudo pip install git-review sumanah@computer:~/test/wikimedia-dev/examples$ git review -s Creating a git remote called gerrit that maps to: ssh://sumanah@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples.git

git-review -- see the doc. Makes it a little easier, less to typ type* also, look at the top of the changeset. with git-review, you can group branches as a "topic" to help with keeping feature development straight we aim to encourage people -- if you are fixing bug n, make a "bug n" branch! To reject a change, I as a code reviewer click Abandon Change. the diff then sits in gerrit for archives, but is removed from the merge queue there is no fulltext search in gerrit there's structured search - by proj, owner, branch, starredbyyou, etc branches as big features of the MediaWiki dev landscape: release branches (19 so far) on core, master (the default branch on trunk). <^demon> https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/CodeReview.git;a=summary "heads" is gitweb's term for branches MediaWiki core & WMF-deployed exts will be tagging releases just as we did in SVN, only they'll be git tags. Any other extension will make its own decisions Tags vs branches: branches are for forking, to maintain a separate feature branch. Traditional branching. Tags are more lightweight, designed to point to an indiv commit. You can delete a tag, but they are not mutable. Designed for tagging releases. "as of this commit, this was exactly 1.2.3" -- useful if you aim to tell people to check out specific versions Commit messages - we should mention bug numbers that are being fixed. no autolinking to bz yet. Note in BZ that the commit is in the merge queue, and link to it. Wait until it's been actually merged to mark the bug resolved-fixed. TODO: come up with a shorthand to autolink from BZ to gerrit changeset TODO: change MediaWiki CR to readonly, no new comments or statuschanges. Very long run: how to write redirects for viewvc -> gitweb? but that can wait till like 2013. TODO: change the configs of automatic bots -- when I commit, where will it spit out?