Before Committing

Formatting and cleaning-up

We expect source code to be formatted and cleaned up using an automated tool prior to submission.

  • For projects that are managed by Eclipse (dpp, dpp.core, dpp.ui, dpp.server, dpp.whiteboard), the code formatter should be called automatically on every save. So there is no need to take any actions.
  • For the projects that are managed by Intellij (currently only dpp.intellij), code formatting styles are configured, but need to be invoked manually through CTRL+ALT+L while the src (or test) folder is selected. Make sure to check "Organize Imports" in the configuration dialog.

Git configuration

  1. Make sure that both "Author" and "Committer" conform to the format: 
    John Doe <john.doe@anywhere.com>

    The following formats are not allowed: "johnd <john.doe@...>" or "johnny <john.doe@...>" or "John <john.doe@...>"

  2. Make sure you commit files with Unix line endings. Refer to the Git manual for more information.

Composing the commit message

  1. Follow the general rule of how Git commit messages are formatted. Refer to the Git manual for more information. In particular, every patch must have an informative short summary or "subject line" (also see next point in the list) and it should have a more detailed explanation below.
  2. In addition, use one of the following type tags in the subject line to make it easier for people to understand what your commit was about:

    [NOP] This commit did not have any effect and only concerns whitespace, removing unused methods, fixing documentation typos, etc.
    [TASK] Adds things that need to be done.
    Includes: [NOP]
    [DOC] Improves JavaDocs or comments.
    Includes: [NOP], [TASK]
    [INTERNAL] Only affects the details of the implementation without any effects to users of the component.
    Includes: [NOP], [TASK], [DOC]
    [API] Affects the interface or dependencies of a component without creating any new functionality or fixing an existing bug.
    Includes: [NOP], [TASK], [DOC], [INTERNAL]
    [REFACTOR] API or INTERNAL changes, which are done using automated tool support. So while REFACTOR changes usually result in large diffs, they are not very error prone. Caution: A refactoring should always be a separate patch, because refactorings are very hard to read.
    Includes: -
    [FIX]
    [FIX] #bug id    		 Fixes a bug. If existing, please attach the SourceForge bug tracker ID.
    Includes: [NOP], [TASK], [DOC], [INTERNAL]
    [FEATURE]
    [FEATURE] #feature id    		 Improves the functionality of the software. If existing, please attach the SourceForge feature tracker ID.
    Includes: [NOP], [TASK], [DOC], [INTERNAL]
    [LOG] Improves Logging with Log4j.
    Includes: [NOP], [TASK], [DOC]
    [UI] Improvements to the user interface.
    Includes: [NOP], [TASK], [DOC], [INTERNAL]
    [JUNIT]
    [STF]    		 Improves testing -- either JUnit tests or STF tests.
    Includes: [NOP], [TASK], [DOC], [INTERNAL]
    [BUILD] Changes the way how the sources are compiled or distributed, e.g. changes to build scripts, MANIFEST files, or update sites.
    Includes: [NOP], [DOC], [TASK]

    The following scope tags can (and should) be used in addition to make it easier to track what part of Saros your commit is changing.

    [E] This commit ONLY affects the Eclipse version of Saros
    [I] This commit ONLY affects the IntelliJ version of Saros
    [S] This commit ONLY affects the Saros Server
    [HTML] This commit ONLY affects the Saros HTML UI
    [CORE] This commit ONLY affects the Saros core

    Example usage: [INTERNAL][I] = Only affects the details of the implementation in IntelliJ.
    If you can't decide on a single type tag, you probably mixed up different concerns and should consider splitting your patch.