Commit guidelines - GhentAnalysis/heavyNeutrino GitHub Wiki

  • Before commiting, ensure the code is compilable

    • It is useless to have a branch in a state with obvious bugs
    • Commit all relevant files together and not one by one

  • Do not commit very short-lived temporary tests

    • It is not really useful to have this, followed by this immediately followed by this, followed by this and this and this in your git history
    • Never put code in comments (both for deprecated code and temporary test code), the old code is anyway somewhere in the git history and the commented code could confuse people and yourself in the future
    • Please always use 4-space indentation as this is used in most of the framework. (Yes, also you Tom :) )

  • Write a useful commit message

    • Make sure the message shows why you are doing this commit
    • Be specific enough, unless it is for something really trivial like a typo or additional comment
    • Bad examples: dd, bugs, Update multilep.cc, p and many more
    • Good examples: this, this or this
    • Consider using multi-line messages to add more specifications
    • Consider add the hash of an earlier commit, if it is useful to refer to it (i.e. when you fix a big introduced in that earlier commit, forgot to commit a file in an earlier commit, or re-implement/cherry-pick the same feature in another branch): example
    • Consider adding a link to an outside pull request (e.g. CMSSW) when useful: example
    • Check some further tips and tricks on the world wide web, like here

  • If you are unsure about the impact of your commit, run the tests

    • It adds an additional commit with a log file in which you can see which test samples failed, and which branches were added/changed/removed
    • If the test shows that you caused unwanted changes, a segfault, or a CMSSW run-time error: fix it asap, and repeat the commit/runTests procedure before pushing
    • Code for running the tests: 
      cd heavyNeutrino/multilep/test/testing
./runTests.py

  • When writing out arrays of variable size ALWAYS initialize the array-size to 0 in-class

    • In cases where the array-size does not get set (say some information is not available for given sample), the unitialized array size might be very large, or might just be 0. This will cause seemingly-random and EXTREMELY HARD to debug errors.