README.commits

   1 The GNOME Utilities project follows some rules on how and what to
   2 commit to the public repository:
   3
   4 0) Ask first. If your changes are major, or could possibly break existing
   5    code, you should always ask. If your change is minor and you've
   6    been working on gnome-utils for a while it probably isn't necessary
   7    to ask. But when in doubt, ask. Even if your change is correct,
   8    somebody may know a better way to do things.
   9
  10 1) Ask _first_.
  11
  12 2) With git, we no longer maintain a ChangeLog file, but you are expected
  13    to produce a meaningful commit message. Changes without a sufficient
  14    commit message will be reverted. See below for the expected format
  15    of commit messages.
  16
  17 Notes:
  18
  19 * When developing larger features or complicated bug fixes, it is
  20   advisable to work in a branch in your own cloned gnome-utils repository.
  21   You may even consider making your repository publically available
  22   so that others can easily test and review your changes.
  23
  24 * The expected format for git commit messages is as follows:
  25
  26 === begin example commit ===
  27 Short explanation of the commit
  28
  29 Longer explanation explaining exactly what's changed, whether any
  30 external or private interfaces changed, what bugs were fixed (with bug
  31 tracker reference if applicable) and so forth. Be concise but not too brief.
  32 === end example commit ===
  33
  34   - Always add a brief description of the commit to the _first_ line of
  35     the commit and terminate by two newlines (it will work without the
  36     second newline, but that is not nice for the interfaces).
  37
  38   - First line (the brief description) must only be one sentence and
  39     should start with a capital letter unless it starts with a lowercase
  40     symbol or identifier. Don't use a trailing period either. Don't exceed
  41     72 characters.
  42
  43   - The brief description might optionally have a "tag", enclosed in
  44     square brackets, detailing what part of the repository the commit
  45     affected, e.g.:
  46
  47       [dictionary] Added history support
  48       [screenshot] Set shadow as default effect
  49
  50     The tag counts as part of overall character count, so try using
  51     a short word.
  52
  53     If the change affects more than one sub-module, do not use a tag.
  54
  55     If the change affects the build environment, always use the "[build]"
  56     tag.
  57
  58   - The main description (the body) is normal prose and should use normal
  59     punctuation and capital letters where appropriate. Normally, for patches
  60     sent to a mailing list it's copied from there.
  61
  62   - When committing code on behalf of others use the --author option, e.g.
  63     git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
  64
  65   - We favour micro-commits: small, atomic changes that do not break
  66     bisection and that are easy to cherry pick. If your commit changes
  67     more than one file or more than one sub-module and it's not a build
  68     fix then you're probably doing it wrong. Break up the changes by
  69     using the -p option to the add command.
  70
  71   - Do NOT EVER, under ANY circumstances rebase a public branch. Do NOT
  72     EVER remove a tag. Your commit rights will be revoked if you decide
  73     to rewrite the history.