Clone wiki

petsc / Home

Daily PETSc testing output

Following PETSc development

The default branch in the PETSc repository is named master.
It contains all features and bug fixes that are believed to be stable and will be in the next release.
Users developing software based on recently-added features in PETSc should follow master:

$ git clone
$ cd petsc
$ git pull               # to get updates

Features that are still experimental will be in the next branch.
To use these features, and perhaps influence their design, follow next and discuss your concerns on the petsc-dev mailing list or by commenting on commits. After cloning, use

$ git checkout next
$ git pull               # to get updates

Use git checkout master to get back to the more stable version.

Production users can follow the maint branch, which contains the latest maintenance release plus any additional bug fixes.
It should always be more stable than the latest tarball.

Contributing to PETSc

By submitting code, the contributor gives irretrievable consent to the redistribution and/or modification of the contributed source code as described in the PETSc open source license.

Please read the code standards chapter of the developer guide before sending patches.

Read detailed instructions for Git

Suggestions for a smooth review of your contributed code:

  • If adding features, include tests which cover them.
  • Test your changes by running with valgrind (use --download-mpich to obtain a valgrind-clean MPI implementation).
  • Test your changes with non-standard configurations of PETSc (in particular, --with-precision=single, --with-scalar-type=complex, --with-64-bit-indices, and --with-clanguage=C++).
  • If your contribution can be logically decomposed into 2 or more separate contributions, submit them in sequence instead of all at once.

PETSc Development Workflow

If you have direct write (push) access to the PETSc repository, you should be familiar with our development workflow. We use a simplified version of the master/next workflow used by the Linux kernel developers. This allows parallel development of multiple features at the same time while preserving a stable master branch. The model is explained in gitworkflows(7) (but we do not currently use a pu branch).

Read detailed instructions for Git

Quick Reference for developing with Git


"Git commands are like irregular verbs in a foreign language: there’s no all-encompassing logic to them, you just have to memorize which words you need for each thing you want to express."

"Git is TeX, what we need is someone to come along and produce LaGit and thus make it usable."

"Git is the perl of revision control systems."

"A mistake most beginning git users make is thinking git is a complete revision control system; it is not. Git, plus an organized mailing list that people actually respond to action items on, plus a rigid set of stylized bookkeeping done by each developer, plus a tyrannical manager of the entire software development process is a complete revision control system."