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, from Chad talk
Notes from my discussion with Chad in mid Feb. To add to this page or related pages. Removing once it's added to the tutorial or related pages.

Added!

To add from Krinkle talk
(Removing once it's in the tutorial.)

Added!

From VE group

 * Get everyone accounts BEFORE the training.

Extras:
 * how to amend their commits to deal with a criticism
 * If the commit is the latest on the given local branch they're working on (that is, they've not made any commits since then), it's as easy as making the changes and doing git commit --amend and then pushing to gerrit. I can't remember the exact process (Roan probably can) if you've made other changes, but I don't believe it's much harder. ^demon (talk) 02:22, 28 February 2012 (UTC)

How do you get commits that are in the merge/review queue
 * Use git review --download 454325346

git review -d ####

How do you download everything at once?
 * Like pull "everything that's unreviewed?" I know of no way to do this. ^demon (talk) 02:22, 28 February 2012 (UTC)

Git-review for Windows?
It looks like the workflow explained here focuses on using a *nix shell. How can git-review be installed on Windows, or anything, so that the workflow descriptions fit for that platform? --siebrand (talk) 21:06, 25 February 2012 (UTC) P.s. A remark like "We should really only use git-review, it makes everything way easier to handle" in "manual setup" seems to imply that MediaWiki development will only be for Linux distro users that have apt and a git-review package, or is that just me thinking badly?
 * We'd really really like to see a git-review package for Windows. Ryan and I talked about it earlier. I don't know the feasibility of doing it, but it's definitely something I'd like to have out there. Installing python + pip + git-review is a PAIN on Windows, so we definitely need to lower that barrier. The current instructions should be fairly portable to non-apt *nix package managers, and the easy_install method should work for any system that's already got python on it (it works for OSX out of the box, no macports or homebrew required) ^demon (talk) 02:24, 28 February 2012 (UTC)

yum install git review
Niklas said:
 * sudo yum install python-pip doesn't actually install pip command anywhere, I had to do the easy_install stuff

Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 23:24, 27 February 2012 (UTC)


 * If easy_install works on Ubuntu too, I'd just as soon suggest that universally (since it works on RedHat-based OSes and OSX). We can always place some footnotes for any esoteric ways we hit. ^demon (talk) 02:27, 28 February 2012 (UTC)

Steps for getting Git installed on Mac via Terminal
Please test these and let me know if they work. In theory, once you complete this, you should be able to complete the Workflow guide steps from within Terminal.

Mac OS X comes with Python (for now) but not the installation programs supported by git and git-review.


 * 1) Open Terminal and change to a directory you're comfortable downloading test Git packages to (such as Downloads or Sites)
 * 2) Download and install the OSX Installer for Git
 * 3) Install pip sudo easy_install pip
 * 4) Install git-review sudo pip install git-review

You should be be able to follow these steps. --Varnent (talk) 01:11, 28 February 2012 (UTC)


 * If you use macports, you can also do port install py27-pip && pip install git-review ^demon (talk) 01:16, 28 February 2012 (UTC)
 * Although if you don't already have the python27 port, it'll add extra needless dependencies. Better off using OSX's built in python like you suggest :) ^demon (talk) 01:20, 28 February 2012 (UTC)
 * Yeah, I played around with a few options - but this one offered the simplest path :)  --Varnent (talk) 01:22, 28 February 2012 (UTC)


 * Trial run of these instructions from Mac: https://gerrit.wikimedia.org/r/#change,2816
 * --Varnent (talk) 01:22, 28 February 2012 (UTC)

How to submit a patch.. I'm confuse
I've never used Git and I try to figures my stuff around it. While reading the section about how to submit a patch, I'm confuse. To whom those instructions are adressed. To core devs, to devs with svn commit access, to peoples with shell access or peoples who have no special acces and submit just a few patches? Also if someone could point me to the good way of tracking a (svn) branches in the Git world for a private deployement that would be great. --Solitarius (talk) 16:36, 6 March 2012 (UTC)
 * My sympathies on the confusion, Solitarius.
 * The "How to submit a patch" instructions are for EVERYONE. Casual developers who have never had Subversion access will follow the exact same procedure as core developers who already have Subversion access.  You just need to get a Gerrit account.
 * I don't know the answer regarding tracking a branch for private deployment, but I think people talked about it within the last 5 weeks on the wikitech-l mailing list. Sumana Harihareswara, Wikimedia Foundation Volunteer Development Coordinator (talk) 18:18, 6 March 2012 (UTC)

Local diff before review
With SVN i would always run `svn diff' before committing.

`git diff' works similarly, but the commits are local, and i may submit several commits for reviewing. I would like to see a diff of all the commits that i'm sending for review before i actually send them in `git review'. A bad commit does less damage in Git than in SVN, but i would nevertheless love to double-check myself to avoid embarrassing commits.

Is anybody familiar with a way to do this? --Amir E. Aharoni (talk) 13:17, 22 March 2012 (UTC)
 * If I got your question right, you want to view the diff between two revisions, git diff revision1..revision2, or my preferred equivalent git diff revision2 ^revision1 which means "all commits in revision2 that are not in revision1". Now, in most cases your "revision2" is simply "master" or HEAD, which includes all your commits. So all you need to find is "revision1", i.e. the revision that includes all commits except your new commits which you'd like to inspect. Usually 'origin/master' or 'origin/branchname' is good. So to wrap it all up: git diff master ^origin/master . - Oren 85.65.7.201 16:07, 22 March 2012 (UTC)
 * I just noticed that 'diff' brings a single diff, while 'log -p' would print each commit separately, which is usually more desired. Mar Garina (talk) 16:20, 22 March 2012 (UTC)

Better branching section
Can anybody please proofread the "Better branching" section? I can't understand it at all - even the grammar doesn't make any sense.

This chapter is probably important, because it mentions "topics" about which everybody is talking, but it doesn't help to understand what should i actually do about these "topics". --Amir E. Aharoni (talk) 15:58, 22 March 2012 (UTC)

Branches and patch sets
It's possible that i misunderstand something basic here, so please clarify this: Does git-review support only one patch set per branch?

Intuitively, i would think that it works like this:
 * create branch bug_425364
 * make a few commits - let's call them 1, 2, 3
 * `git review' sends commits 1, 2, 3 for review
 * make some more commits - let's call them 4, 5, 6
 * `git review' sends commits 4, 5, 6 for review
 * when everything is reviewed, merge bug_425364 to master.

After a day of trying to work with Gerrit i'm starting to understand that it's probably not how it works and that my thinking is probably stuck too hard in the SVN and GitHub workflow. So, does git-review send only one patch set per branch? It's kinda weird that i have to create a branch for every remote patch set. If that's indeed the requirement, i'm OK with it, but the current documentation is very unclear about this. --Amir E. Aharoni (talk) 15:58, 22 March 2012 (UTC)


 * When you do several commits (1, 2, 3) locally and then use git-review, you will be shown a warning about sending said 3 commits. git-review even ask you to confirm by entering yes. The result would be three changes (let s says 1001 1002 1003), each holding a commit and being dependent to the next change holding the next commit. To sum it up, the dependency in gerrit would be:


 * 1001 depends on whatever commit your local branch was at
 * 1002 depends on change 1001
 * 1003 depends on change 1002


 * Same with 4, 5, 6. That will provide 3 more changes let s says 1004 1005 1006 which have the following dependencies:


 * 1004 depends on change 1003
 * 1005 depends on change 1006
 * 1006 depends on change 1005


 * If any of those changes is rejected, the following one will have to be rebased which is painful. So usually we use branching to have different commits not generating dependent changes in Gerrit.


 * Whenever a change is reviewed, someone will ask Gerrit to merge the change. Gerrit will then apply it to the current master. It will then be available in origin/master for everyone :-)


 * So as a summary:
 * A change being reviewed mean that it will be merged by Gerrit. You will not have to merge your local branch, you could even drop it (git branch -D ) as soon as you send the commits to Gerrit :-]


 * Please come see me on IRC, we can even arrange a video chat if you want :)
 * Antoine &#34;hashar&#34; Musso (talk) 17:54, 22 March 2012 (UTC)
 * OMFG, does this really mean that i have to create a new branch for every single commit? It's not that it's bad, but that is really surprising for anybody who comes from other workflows even if they are Git-based, so the documentation must say it explicitly. --Amir E. Aharoni (talk) 19:08, 22 March 2012 (UTC)

It kind of works like this - say you base your first commit 017c09db on revision fe941eb. It will be submitted to gerrit as change 3366 in "Patch set 1" (there will be  - you can see them in gitweb). So now commit 017c09db is your HEAD. But you want to improve 017c09db and have "Patch set 2" you do the following: (1)you reset the pointer back to commit fe941eb: git reset --soft HEAD^ Now commit 017c09db is remembered as.

(2) you commit the change using the commit message from 017c09db: git commit -c ORIG_HEAD Thich means "commit everything in the working directory, so that parent will be fe941eb, but please take commit message from ORIG_HEAD (in our case 017c09db) and let me edit it". This way a new commit (say f48f425) will be submitted to gerrit, but this one will be based on commit fe941eb too. So you will have a tree: fe941eb (parent) - 017c09db (child); fe941eb (parent) - f48f425 (child). Change 017c09db will stay kind of abandoned in the git repository and will not be used for anything unless explicitly referred. Those steps above can be done with a roughly equivalent command:

git commit --amend

which goes back to the commit fe941eb and submits the change giving you a chance to edit the message. Then we need to send it back to gerrit. We can do this using git push gerrit HEAD:refs/changes/3366 Strangely this "ref" looks sane this time. The new pointer will be created  for "Patch Set 2". Alternatively, "git review" should be smart enough to do this "git push" command for you. Another thing, if you want to figure out how does your changeset look like, what are its commit numbers etc. you can issue a command: ssh -p 29418 gerrit.wikimedia.org gerrit query 3366 for example:

$ ssh wikimedia gerrit query 3366 --patch-sets change I51f183143bf69b62b3ea2c1f77107431112dcb3f project: mediawiki/extensions branch: master id: I51f183143bf69b62b3ea2c1f77107431112dcb3f number: 3366 subject: Modify script to work without .gitmodules file owner: name: saper email: saper@saper.info url: https://gerrit.wikimedia.org/r/3366 lastUpdated: 2012-03-22 11:38:51 UTC sortKey: 001bdf3a00000d26 open: false status: MERGED patchSets: number: 1 revision: 017c09dbf76ff46c2a89aad626da6643959a3089 ref: refs/changes/66/3366/1 uploader: name: saper email: saper@saper.info

number: 2 revision: f48f42538032def2a8246287fa9ccc2aaf403c5e ref: refs/changes/66/3366/2 uploader: name: saper email: saper@saper.info

number: 3 revision: 1912b3f1705ff2177f1476fecaa5baf0ae4a0779 ref: refs/changes/66/3366/3 uploader: name: saper email: saper@saper.info

number: 4 revision: 02513c79a06f228cb75c7465655893ac4680995c ref: refs/changes/66/3366/4 uploader: name: saper email: saper@saper.info Boy, I learned this the hard way. « Saper // talk » 22:04, 22 March 2012 (UTC)
 * Thanks a lot for the detailed explanation.
 * What seems weird to me here is that if i understand correctly --amend is supposed to be used as part of the normal process. I would expect --amend to be used only when you made a really bad commit that you don't even want to push for review or misspelled the commit message. It makes more sense to me that a commit that is kinda OK, but should be improved before merging to the master branch, should be improved in a subsequent commit and not by using --amend. --Amir E. Aharoni (talk) 06:33, 23 March 2012 (UTC)


 * That is really part of the workflow. Gerrit has patch set which you can edit by amending the commit. Since the patch set is hold by Gerrit, even if it cause any mistake or is half finished, it is not going to cause any trouble to other developers. That is what make that workflow powerful.
 * So you can indeed improve your commit in a subsequent commit, but nothing get merged meanwhile until your commit it is fully OK, not just kinda OK :)
 * Antoine &#34;hashar&#34; Musso (talk) 20:23, 23 March 2012 (UTC)

The .gitreview file
The .gitreview file is being talked about as an important part of the process of using Gerrit, but i don't see any explanation about this here. --Amir E. Aharoni (talk) 16:01, 22 March 2012 (UTC)


 * That is just a basic configuration file to be used by git-review so it can find Gerrit instance.
 * git-review --setup should generates it IIRC.
 * Antoine &#34;hashar&#34; Musso (talk) 17:56, 22 March 2012 (UTC)

How to mark commits that should go into 1.19 or 1.18
I have a bunch of changes that should be backported to 1.19 or 1.18. One of them (gerrit change 3365) is still pending review. How do I mark those changes as candidate for the release branches (just like 1.19, 1.18 tags in Special:Code)? If I submit changesets against REL1_18 or REL1_19, should I do this after master change is reviewed or should I go in parallel? Is there any way to say those changes are related (except for comments of course)?

I fixed issues with PostgreSQL installer/updater that people complained in 1.18.* branch so I hope we can fix this in 1.18.3 « Saper // talk »  22:09, 22 March 2012 (UTC)