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)

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)