Repository

From collectd Wiki
(Difference between revisions)
Jump to: navigation, search
(Created initial page based on an email to the mailing list.)
 
(Apply clang-format to *.cc as well.)
 
(14 intermediate revisions by 5 users not shown)
Line 5: Line 5:
 
The official repository is available from:
 
The official repository is available from:
   
git://git.verplant.org/collectd.org
+
git://git.verplant.org/collectd.git
   
 
To clone the repository use:
 
To clone the repository use:
   
$ git clone git://git.verplant.org/collectd.org
+
$ git clone git://git.verplant.org/collectd.git
   
 
=== Github mirror ===
 
=== Github mirror ===
Line 15: Line 15:
 
If you're more comfortable using ''Github'' you can use the mirror available there. Its web address is:
 
If you're more comfortable using ''Github'' you can use the mirror available there. Its web address is:
   
http://github.com/octo/collectd
+
https://github.com/collectd/collectd
   
 
The public clone URL is:
 
The public clone URL is:
   
git://github.com/octo/collectd.git
+
git://github.com/collectd/collectd.git
  +
  +
=== How to check out a specific branch ===
  +
  +
If you [[Submitting patches|sent a patch]] to the [[mailing list]], chances are you were told that
  +
<blockquote>“… the changes are in the ''‘foobar’'' branch.”</blockquote>
  +
Usually this happens when a patch is not yet ready to be applied to the ''master'' branch (see below) and needs some review. For example, the main developers did some changes and ask you to verify that they didn't accidentally break anything.
  +
  +
To check out this ''‘foobar’'' branch, you have to ''clone'' the repository first, using the ''git&nbsp;clone'' command (see above). After that is done, “cd” into the newly created <code>collectd/</code> directory. There you have to create a local copy of the branch, using:
  +
git branch --track ''foobar'' remotes/origin/''foobar''
  +
Then you have to ''check&nbsp;out'' that branch:
  +
git checkout ''foobar''
  +
  +
For further documentation on ''Git'', please refer to [http://git-scm.com/documentation the Git homepage]. There you'll find documentation for beginners, SVN converts, computer scientists (people comfortable with terms such as “directed acyclic graph”) and much more.
   
 
== Organization ==
 
== Organization ==
   
We maintain three branches: One development branch (named “master”) and two bugfix branches. The first bugfix branch corresponds to the latest release, the second bugfix branch corresponds to the second latest release. Those are the versions we provide bugfixes for. At the time of this writing, those versions were “collectd-4.8” and “collectd-4.7”.
+
We maintain three branches: One development branch (named “master”) and two bugfix branches. The first bugfix branch corresponds to the latest release, the second bugfix branch corresponds to the second latest release. Those are the versions we provide bugfixes for. At the time of this writing (August 2010), those versions were “collectd-4.10” and “collectd-4.9”.
   
 
◆ ◄──────── master ⎫
 
◆ ◄──────── master ⎫
Line 46: Line 46:
 
[[File:Screenshot gitk branches.png|thumb|Screenshot of ''gitk'' in which the three branches are visible nicely. Also note the now defunct “collectd-4.6” branch near the bottom.]]
 
[[File:Screenshot gitk branches.png|thumb|Screenshot of ''gitk'' in which the three branches are visible nicely. Also note the now defunct “collectd-4.6” branch near the bottom.]]
   
Bugfixes are applied to the earliest branch possible. If a bug existed for a while, this is probably the “bugfix1” branch. If the bug was introduced in the latest release (i.&nbsp;e. “collectd-4.8” currently), then the fix is applied to “bugfix0”. If the commit fixes a bug that has not yet been released or adds a new feature, it is committed to the “master” branch. From time to time, the “bugfix1” branch is merged into the “bugfix0” and the “bugfix0” branch is merged into “master”, so that bugfixes are included in all appropriate branches.
+
Bugfixes are applied to the earliest branch possible. If a bug existed for a while, this is probably the “bugfix1” branch. If the bug was introduced in the latest release (i.&nbsp;e. “collectd-4.9” currently), then the fix is applied to “bugfix0”. If the commit fixes a bug that has not yet been released or adds a new feature, it is committed to the “master” branch. From time to time, the “bugfix1” branch is merged into the “bugfix0” and the “bugfix0” branch is merged into “master”, so that bugfixes are included in all appropriate branches.
  +
  +
With the release of [[version 4.9]] the “collectd-4.8” branch became the new “bugfix1” branch and the “collectd-4.7” branch is now obsolete. ''Release&nbsp;4.7.5'' was created so that the “collectd-4.7” version does not fall into oblivion with unreleased bugfixes still in the appropriate branch.
  +
  +
== Automatic formatting ==
  +
  +
The following recommended configuration will automatically format <code>.c</code>, <code>.h</code> and <code>.proto</code> files when committing them to the repository.
  +
  +
# .git/config
  +
[filter "clang-format"]
  +
clean = /usr/bin/clang-format -style=LLVM
  +
smudge = /usr/bin/clang-format -style=LLVM
  +
  +
# .gitattributes
  +
*.c text filter=clang-format
  +
*.cc text filter=clang-format
  +
*.h text filter=clang-format
  +
*.proto text filter=clang-format
  +
  +
=== Merging ===
  +
  +
In order to merge or rebase a pull request that is based on a non-normalized version of the repository, you can use the ''recursive'' merge strategy with the ''renormalize'' option to let Git reformat all participants in a three way merge, resolving the majority formatting based merge conflicts.
  +
  +
git merge -s recursive -X renormalize $branch
  +
  +
=== vim ===
  +
  +
If you're using ''vim'', you can configure it to run ''clang-format'' on each save:
  +
  +
# ~/.vimrc
  +
set autoread
  +
autocmd BufWritePost *.c !clang-format -style=LLVM -i <afile>
  +
autocmd BufWritePost *.cc !clang-format -style=LLVM -i <afile>
  +
  +
== Wiki templates ==
  +
  +
There are a couple of templates that make it easy to point to stuff in the repository.
   
With the release of [[version 4.8]] the “collectd-4.7” branch became the new “bugfix1” branch and the “collectd-4.6” branch is now obsolete. ''Release&nbsp;4.6.5'' was created so that the “collectd-4.6” version does not fall into oblivion with unreleased bugfixes still in the appropriate branch.
+
* [[Template:GitFile|GitFile]]<br />Adds a link to a file in the repository. For example, <code><nowiki>{{GitFile|README}}</nowiki></code> yields: {{GitFile|README}}
  +
* [[Template:GitBranch|GitBranch]]<br />Adds a link to a Git branch. For example, <code><nowiki>{{GitBranch|master}}</nowiki></code> yields: {{GitBranch|master}}
   
 
[[Category:Development]]
 
[[Category:Development]]

Latest revision as of 23:06, 6 December 2016

The source code of collectd is organized in a Git repository.

Contents

[edit] Location

The official repository is available from:

git://git.verplant.org/collectd.git

To clone the repository use:

$ git clone git://git.verplant.org/collectd.git

[edit] Github mirror

If you're more comfortable using Github you can use the mirror available there. Its web address is:

https://github.com/collectd/collectd

The public clone URL is:

git://github.com/collectd/collectd.git

[edit] How to check out a specific branch

If you sent a patch to the mailing list, chances are you were told that

“… the changes are in the ‘foobar’ branch.”

Usually this happens when a patch is not yet ready to be applied to the master branch (see below) and needs some review. For example, the main developers did some changes and ask you to verify that they didn't accidentally break anything.

To check out this ‘foobar’ branch, you have to clone the repository first, using the git clone command (see above). After that is done, “cd” into the newly created collectd/ directory. There you have to create a local copy of the branch, using:

git branch --track foobar remotes/origin/foobar

Then you have to check out that branch:

git checkout foobar

For further documentation on Git, please refer to the Git homepage. There you'll find documentation for beginners, SVN converts, computer scientists (people comfortable with terms such as “directed acyclic graph”) and much more.

[edit] Organization

We maintain three branches: One development branch (named “master”) and two bugfix branches. The first bugfix branch corresponds to the latest release, the second bugfix branch corresponds to the second latest release. Those are the versions we provide bugfixes for. At the time of this writing (August 2010), those versions were “collectd-4.10” and “collectd-4.9”.

 ◆ ◄──────── master   ⎫
 │╲                   ⎪
 │ ╲                  ⎪
 │  ◆ ◄───── bugfix0  ⎬  branch heads
 │  │╲                ⎪
 │  │ ╲               ⎪
 │  │  ◆ ◄── bugfix1  ⎭
 │  │  │
 │  │  │
 ◇◅─│──│──── bug not released yet / new feature
 │  │  │     (available in “master” only)
 │  │  │
 │  ◇◅─│──── fix for bug introduced in the newest version
 │  │  │     (available in “bugfix0” and “master”)
 │  │  │
 │  │  ◇◅─── fix for bug introduced in an earlier version
 │  │  │     (available in “bugfix1”, “bugfix0” and “master”)
 │  │  │
(thumbnail)
Screenshot of gitk in which the three branches are visible nicely. Also note the now defunct “collectd-4.6” branch near the bottom.

Bugfixes are applied to the earliest branch possible. If a bug existed for a while, this is probably the “bugfix1” branch. If the bug was introduced in the latest release (i. e. “collectd-4.9” currently), then the fix is applied to “bugfix0”. If the commit fixes a bug that has not yet been released or adds a new feature, it is committed to the “master” branch. From time to time, the “bugfix1” branch is merged into the “bugfix0” and the “bugfix0” branch is merged into “master”, so that bugfixes are included in all appropriate branches.

With the release of version 4.9 the “collectd-4.8” branch became the new “bugfix1” branch and the “collectd-4.7” branch is now obsolete. Release 4.7.5 was created so that the “collectd-4.7” version does not fall into oblivion with unreleased bugfixes still in the appropriate branch.

[edit] Automatic formatting

The following recommended configuration will automatically format .c, .h and .proto files when committing them to the repository.

 # .git/config
 [filter "clang-format"]                                                                                                                      
 clean = /usr/bin/clang-format -style=LLVM                                                                                        
 smudge = /usr/bin/clang-format -style=LLVM                                                                                       
 # .gitattributes
 *.c     text filter=clang-format
 *.cc    text filter=clang-format
 *.h     text filter=clang-format
 *.proto text filter=clang-format

[edit] Merging

In order to merge or rebase a pull request that is based on a non-normalized version of the repository, you can use the recursive merge strategy with the renormalize option to let Git reformat all participants in a three way merge, resolving the majority formatting based merge conflicts.

 git merge -s recursive -X renormalize $branch

[edit] vim

If you're using vim, you can configure it to run clang-format on each save:

 # ~/.vimrc
 set autoread
 autocmd BufWritePost *.c !clang-format -style=LLVM -i <afile>
 autocmd BufWritePost *.cc !clang-format -style=LLVM -i <afile>

[edit] Wiki templates

There are a couple of templates that make it easy to point to stuff in the repository.

Personal tools
Namespaces

Variants
Actions
Navigation
Tools