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 <branchname>) 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 "hashar" 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 ref/changes/66/3366/1 - 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 (HEAD) back to commit fe941eb:

git reset --soft HEAD^

Now commit 017c09db is remembered as ORIG_HEAD.

(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 refs/changes/66/3366/2 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 "hashar" Musso (talk) 20:23, 23 March 2012 (UTC)

OK, but what happens if i made a commit, submitted it for review, and then i want to make another commit based on the first one before it is reviewed? `git review' doesn't let me do that. I don't want to amend the first one, i want to keep them separate. --Amir E. Aharoni (talk) 13:13, 24 March 2012 (UTC)

I took one approach. Don't listen to what they say, check on your own :) For example, before I read Git Community Book I was really struggling. Another good thing to read is

git --help rev-parse
gtt --help commit

One of the things I discovered that you don't "undo" or "overwrite" bad commits - you just go back one or more levels into the commit tree and commit from there again. It's simply like editing an older revision of the MediaWiki page. I got "git commit --amend" as a shortcut to do exactly this - go up and commit existing working tree (index) anew.

Now what happens if you have second commit on top of your commit you have submitted to gerrit already. If you push then you will get a message

! [remote rejected HEAD -> refs/for/master (squash commits first)]

In this case you need to forget your second commit by going back (like git reset described above). Not sure if git commit --amend is smart enough to go back one more level up.  « Saper // talk »  15:32, 24 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 "hashar" Musso (talk) 17:56, 22 March 2012 (UTC)

Well, it doesn't seem to. When i run it in the repo extensions/TranslationNotifications, i get the message:

No '.gitreview' file found in this repository.
We don't know where your gerrit is. Please manually create 
a remote named gerrit and try again.

So how do i create it? --Amir E. Aharoni (talk) 14:08, 27 March 2012 (UTC)

man git-review has a description of the format. The easiest way is to copy it from another repository and amend it. Antoine "hashar" Musso (talk) 14:13, 27 March 2012 (UTC)

Solution for missing .gitreview file on CentOS:

1. Create file and the folder if necessary: ~/.config/git-review/git-review.conf
2. Open file and paste this content:

[gerrit]
defaultremote=origin

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)

git review -d

This page suggests doing git fetch ssh://<username>@gerrit.wikimedia.org:29418/mediawiki/ <ref> && git checkout FETCH_HEAD when starting to amend. Other people on IRC suggested using git review -d. Is there a reason to use one or the other? Am i confused completely and they are completely different things?

(Ceterum censeo that it's usually better to use consecutive commits in a branch rather than amends, but if that's what we decide to do, it should at least be documented clearly.) --Amir E. Aharoni (talk) 08:51, 28 March 2012 (UTC)

git-review is a helper script. Both commands above are basically equivalent. Indeed, we should probably only describe one of the way or make it clear that they are alternative ways to do the something. git-review -d 1234 is just easier to remember and faster to type, it will also take care of finding the latest patchset available. Compare with git fetch gerrit refs/changes/34/1234/1 && git checkout FETCH_HEAD (assuming we want to fetch patchset 1).

Antoine "hashar" Musso (talk) 10:24, 5 April 2012 (UTC)

How to see the list of projects/repositories in gerrit?

How to see the list of MediaWiki projects/repositories in gerrit? O_o The absence of such list is very confusing for me O_o even https://gerrit.wikimedia.org/r/gitweb is redirecting to gerrit main page... VitaliyFilippov (talk) 16:17, 3 April 2012 (UTC)

Click "Admin" and "Projects" at the top. --Amir E. Aharoni (talk) 16:24, 3 April 2012 (UTC)

I mean - how an unauthorized user can see them? VitaliyFilippov (talk) 10:11, 5 April 2012 (UTC)

There is currently no way to list all projects hosted on WMF Gerrit unless you are an administrator. Gerrit simply does not supports it. Our bug report is bug 35510; Upstream issue is http://code.google.com/p/gerrit/issues/detail?id=303 Antoine "hashar" Musso (talk) 10:28, 5 April 2012 (UTC)

Maybe patch it in some way and allow gitweb access to the project list? https://gerrit.wikimedia.org/r/gitweb VitaliyFilippov (talk) 10:34, 5 April 2012 (UTC)

MediaWiki Git access through proxy

VitaliyFilippov (talk) 10:33, 5 April 2012 (UTC)

Don't know if this a Git or Gerrit bug, but I successfully clone the repository without https proxy and fail to do it through a https proxy:

https_proxy=http://proxy.custis.ru:3128/ git clone https://gerrit.wikimedia.org/r/mediawiki/core.git mediawiki-wm-git
Cloning into 'mediawiki-wm-git'...
fatal: https://gerrit.wikimedia.org/r/mediawiki/core.git/info/refs not valid: is this a git repository?

For Ubuntu systems, the discussion at comp.version-control.git and the question on stackoverflow.com blame libcurl3-gnutls and libgnutls26 packages for the problem. Updating those (and dependencies) should make the problem disappear. User wadesworld had to do update manually to get the problem fixed:

sudo dpkg -i libp11-kit0_0.6-0ubuntu2_amd64.deb
sudo dpkg -i libgnutls26_2.12.14-3_amd64.deb
sudo dpkg -i libcurl3-gnutls_7.22.0-3ubuntu1_amd64.deb