GitSharp/Contributing

From eqqon

Contents 1 How You can Contribute to the Project's Success 2 Let's Collaborate 3 Getting Started with Git, GitHub and Coding 4 File a Bug Report 5 Short Contributor's How-To 6 Porting from JGit

How You can Contribute to the Project's Success

A list of things you can do with increasing level of difficulty :)

• Link to us!
• Blog abut GitSharp
• Try it out and give us Feedback. We appreciate it!
• Hack together small examples of usage and publish them
• Code: Fork from henon/GitSharp and ...
  • [Easy] Write test cases for an untested API function. This way you get into the code really fast!
  • [Medium] Pick one of the open tasks on the issue tracker and pursue it
  • [Hard] Implement one of the missing command line commands
  • [Only for hardened veterans :D] Implement (or port over from original git) a missing feature that not even jgit supports.

If you are doing some coding make sure you get in touch with us. We can coordinate efforts and give you hints.

Let's Collaborate

Via the Mailing List

Feel free to join the git# mailing list

We will post status updates regularly to keep you informed about the project status.

Via IRC

Visit us on freenode in Channel #GitSharp

Getting Started with Git, GitHub and Coding

If you never contributed to a github project or are a git newbie read the Collaborative Github Workflow guide.

The typical collaborative workflow with git can be described like this: Fork the repository at github, clone into your local repo and start coding. When you are done with the task, push to your fork on github and send a pull-request to henon. After other contributor's commits have been applied to the main repository your fork needs to be updated by pulling from henon/GitSharp. If you are not familiar with this workflow read the in-depth description with git commands.

File a Bug Report

Please file any bugs, requests or other feedback in our issue tracker. Specify the release version number or the commit hash of the actual GitSharp version you are using when reporting bugs.

Short Contributor's How-To

• Join the mailing list and if you like to discuss/ask things in realtime the IRC channel #GitSharp on freenode.
• See what work is open at the issue tracker.
• Please *do not* use github fork queue, just pull from henon/GitSharp to get other's changes
• Feel free to include your copyright to the files you contributed something to
• When you feel like your contribution should go into the main branch (henon/GitSharp) then post on the ML.
• When you corrupted your fork read Fixing Corrupt Git Branch

Porting from JGit

Porting of the core is done. As soon as there are new commits in jgit we are going to port them over. However, there is still a lot of work to do, i.e. port implementations of CLI commands from jgit/pgm or port unit tests from the original git to test the command line.

• Port small portions with few dependencies first and comment out code that is ported but can not yet compile due to missing dependencies.
• Please do not rename java classes, methods, constants etc. or else porting of dependent code will be more complicated and error prone. We are going to rename according to .NET conventions as soon as all code is ported.
• Please do keep order of methods, properties,... in sync with the Java version. If you work with a refactoring tool, make sure to configure it accordingly to this recommendation.
• Please consider committing small and atomic change-sets (instead of committing all your changes at the end of the day) in order to ease reviewing, merging and cherry-picking. You will benefit from it next time you pull.
• Check out the list of non-trivial Java to C# conversions.
• Please make sure you base your porting work on the same version of the jgit code as all other developers to avoid inconsistencies. As soon as jgit a commit is ported over it will be pushed up to that repostiory.