Note The repositories contain the skeleton code only, this means you need to run after you have cloned the repository, see the README file for additional instructions and notes
cclive.git (Browse)
$ git clone git://
cclive-np.git (Browse)
$ git clone git://
Tip cclive-np.git holds misc. files related to the cclive project, including this website


The repository contains the maint, the maint-0.7, the next and the master branches.


Reserved for the maintenance releases


For the maintenance releases of 0.7


Holds the last release, this branch is considered to be stable — it gets updated only when the next branch graduates (merged into master)


The code currently being developed for the next release


Guidelines: Code of conduct

Confirm against the current code

Make sure your patches apply against the current project git repository code. The developers follow the git repository code changes in the next branch.

Post early, listen to feedback

Post your patches (to cclive-devel list) early and listen to the feedback. Never assume that your patch gets automatically committed after posting it. If you wish to have your patch committed, then commit to the discussion.

If your patch has not received any feedback after the initial post:

  • It may have been committed to the repo already (check to confirm)

  • No one has taken a look at it yet (be patient)

  • You didn’t read this page thoroughly (read again)

  • The mail got lost (check the archives)

Major changes

Discuss any major changes on the cclive-devel mailing list, first.


Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program.


Sign-off your patches.


Indent your code to the requirements.


See also Richard Jones' guide on how to get your code into an open source project.


Use git(1)

Don’t be square.

Use git-send-email(1)

Felipe Contreras has written a guide on how to use this command effectively.

Split large changes

Split large changes into series of smaller patches (self-contained if possible). Include an explanation of each patch and how the sequence of patches fits together.

Describe changes

In each commit message, describe all of the changes you are making, the subject line describes only one. Write good git commit messages, for example:

Header line: explaining the commit in one line

Body of the commit message, which is a few lines of text explaining
the changes in details, possibly giving some background about the
issue being fixed, etc.

The body of the commit message can be >1 paragraphs, and please use
proper word-wrap, keeping columns shorter than 74 characters. This
way "git log" will show everything nicely even when it is intended.

Reported-by: Whoever-reported-it
Signed-off-by: Name <email>

Sign-off your patches

Please either send signed-off patches or a pull request with signed-off commits. This means adding a line that says:

Signed-off-by: Name <email>

at the end of each commit message, indicating that you wrote the code and have the right to pass it on as a Free Software patch. For example, with git-commit(1) you would normally use the -s switch.

Note 2013-05-23: The project will no longer accept patches that have not been "signed-off"

Alternative methods of posting

Pull requests

Pull requests are OK, although patches are preferred. You can post the requests to the cclive-devel mailing list.

Formatting conventions

We have strict code-formatting conventions, particularly, with the new code.

  • Keep lines under 80 characters (72 is preferred)

  • Use spaces, not tabs for indenting

C source code

You can use astyle(1) for reformatting:

$ astyle --style=gnu -c --indent=spaces=2 foo.cpp

Code indentation conventions

Number of spaces for each indentation level is 2.

Note The source code must not contain any tab characters

Other conventions

vim (modeline)

Each source code file .{cpp,h} in the cclive project must end to line:

// vim: set ts=2 sw=2 tw=72 expandtab: