Manual:Pywikibot/Gerrit/ja

Terminology

 * Git - a version control system. Replaces SVN.
 * Gerrit - a code review platform (http://gerrit.wikimedia.org). Replaces Special:CodeReview
 * core - formerly known as "rewrite".
 * compat - formerly known as "trunk".

Git clients

 * Windows users: We recommend you use TortoiseGit with Git for windows. Install TortoiseGit first!
 * OSX/Linux: commandline git - http://git-scm.com/ For example in order to download core via commandline:

To update:

If you're lazy and want to be able to do that all at once, you can do:

(copied from ) [add  to make this alias stick for all projects]

Note that the repositories are somewhat large (~70MB). If this is an issue, use to just retrieve the latest versions.

Using SVN
But wait... I don't want to use Git. Can I still use SVN? Yes! For this example, I'm going to use pwb-core, however you can easily switch compat in.

Updating is as simple as

Windows users may also use the GUI extension TortoiseSVN. You'll find the documentation here.

URLs
Your client will probably ask you for the repository url. The urls follow the format of:.

So for core:.

So for compat:.

Nightly distributions
You can download the whole packages or browse the source code via nightly distributor in Wikimedia Labs

For developers
How to submit patches...configure git/gerrit. etc.

Follow steps in Gerrit/Getting started and run this: and after modifying codes follow steps in Gerrit/Tutorial


 * Windows: Developer using Windows may also use Gerrit/TortoiseGit tutorial for further informations.

Example (step-by-step)
So for example if you want to work with compat (formerly known as trunk), do the following, step-by-step:
 * 1) setup your software:
 * 2) if not done already for svn access; create an SSH key, a developer account and add your public key to gerrit as well as to wikitech
 * 3) install 'git' package
 * 4) install 'git-review' package
 * 5) * the one by openstack, NOT the one by Facebook
 * 6) * any version like 1.12, 1.21, but NOT v1.18
 * 7) clone and setup your repo:
 * 8) clone the git repo with all submodules by using (like  )   and wait, this step will take some time
 * 9) enter the directory
 * 10) config git setting for this repo/directory only (not global, in case e.g. you have different pseudo for multiple projects)   and   in order to configure this globally, use the   parameter
 * 11) config your terminal/console to output english messages (in order to work properly with git review, see Gerrit/git-review)   this has to be done every time a new console is started, in order to configure this permanently, put this into your   or similar setup file
 * 12) setup git review for this repo only   and enter your   again, this is an important step - if you forget it, according to Gerrit/Tutorial, the final   below (needed to commit your changes for review) will fail - though this can be still solved then
 * 13) work with the repo, e.g. commit patches for review:
 * 14) switch to the master branch (might not be needed)
 * 15) update the current branch to revision online (like  )
 * 16) create your own local temporary branch for working   and try to choose a   with the help of the branch naming tips available - the branch can be removed when not needed anymore with
 * 17) now write some code; see the Git commands add, rm and mv to add, remove or rename files - when you're ready go to the next step
 * 18) commit your changes to your local temporary branch with   (you can use   instead of   and   instead of  ) and, as used from svn, enter a meaningful commit message, e.g. a short description of your code changes
 * 19) * See Gerrit/Commit message guidelines.
 * 20) optionally check your changes by looking at the committed data   and make sure that you are sending what you wanted to
 * 21) send the data to the online repository, resp. gerrit for review (like  )
 * 22) finally go to Gerrit, click on your change and write a reviewer name in the input box near the "Add Reviewer" button
 * 23) optionally/opt-in further settings:
 * 24) * enable RCS keywords expansion (like svn:keywords ) by using git hooks (explained in detail here - german only)
 * 25) ** for compat (trunk):
 * 26) ** for core (rewrite):
 * 27) ** (may be we should consider using the git-rcs-keywords module as mentioned in dealing-with-svn-keyword-expansion-with-git-svn)

Bugzilla
Patches will be linked to a bugzilla bug automatically if you mention 'Bug 12345' in the summary or 'Bug: 12345' on a line just before 'Change-Id: ....'

jenkins-bot messages
https://integration.wikimedia.org/ci/job/pywikibot-core-tox-flake8/2591/console : FAILURE in ?s (non-voting) The patchset committed did not pass flake8 code style checks. That says nothing about the functionality of the code but about the syntax and style.

https://integration.wikimedia.org/ci/job/pywikibot-core-tox-flake8-docstrings-mandatory/560/console : FAILURE in ?s (non-voting) The patchset committed did not pass mandatory pep257 code style checks. That says nothing about the functionality of the code but about the inline documentation.

https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose/1448/console : FAILURE in ?s (non-voting) The patchset committed did not pass pre-merge test suite. That indicates the code fails the basic tests, but a pass says nothing about the functionality of the modified code. There is a more extensive set of tests which developers should run pre-submission, and will run post merge.

This change could not be automatically merged with the current state of the repository. Please rebase your change and upload a new patchset. The pachset cannot be merged automatically into current HEAD. Please consider Gerrit/Advanced usage for a solution.

More info about this can be found in Gerrit/Tutorial and Gerrit/Tutorial.