Git/Tips

A list of Git tips and tricks

Dealing with old branches
If you've been working with git for a while you probably have a bunch of old crufty branches laying around that you don't need anymore. The ones you definitely don't need anymore are ones that have already been merged back to master. You can identify these with:

Similarly, when submitting a change for review, you can have your branch automatically deleted once it's been merged by Gerrit:

Pre-commit checks
Git allows you to define checks a commit has to pass via hooks (see  for details). You should keep in mind that you have to define hooks separately for every (for example extension's) repository and that they are not copied by, so you have to create some procedure suiting your personal work patterns for how to keep them organized.

Start by enabling the pre-commit sample installed by Git. It disallows non-ASCII filenames and trailing whitespace.

Disallow commits to master
Committing to  in your local repository usually isn't what you want. To disable, put this sniplet at the top:

You could also disallow commits to other branches (REL1_20, etc.), but protecting against  is enough in most cases.

Run php -l on PHP files
It's probably a good idea to check whether any PHP files you added or changed pass a simple  test. To enable this, put this sniplet before the final  line:

Running test suites
As the pre-commit checklist suggests, you should run tests before submitting a change. In a rational world, this tedious task is left to a robot, in the real world where despite frequent a/b tests for UI tidbits this isn't even on the radar, you have to build the robot yourself. Thankfully, Git offers all that is needed in the hooked form of.

The following example somewhat tests the parser and the SQLite backend (cf. the Jenkins jobs repository for further inspiration):

Obviously, it's very necessary to adapt this hook to your personal workspace and also not use the same for  as for extensions. Running the test suite as an  job allows you to continue working while the test runs in the background and you'll be mailed the results once it ends. This setup assumes that you run one test suite at a time; if you want to run more in parallel, you can reference the SHA1 of  in   or even try   but be reminded that each clone will consume more than 200 MByte of disk space.

What tests you should run depends on your field of work. If you're working on parser bits, running those tests may be enough. If you plan complex changes to the database schema, you can test fresh installs and running update.php from older installations. If you're working on extensions, you can clone  and tags (not branches, the latter are moving targets)   and   and see whether your code is still compatible with them.

If you develop on a box with few resources, but have access to more powerful machines on the net, you can create bare repositories on the latter and use the hook  in a similar fashion on them (the commit is passed as  ). You then just have to  to start the test suite.

View source code
gerrit wants to show you code changes, but makes it difficult to navigate to see projects and their code. (An upgrade to gerrit 2.6 and a change from gitweb to gitblit will improve things.)
 * If you're logged in, click Admin > Projects to see all projects, then click a project > Branches > master (gitweb)
 * If you're not logged in, view https://gerrit.wikimedia.org/r/#/admin/projects/