GitSharp/Contributing
From eqqon
m (→Getting Started with Git, GitHub and Coding) |
m (→Porting from JGit) |
||
Line 53: | Line 53: | ||
* 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 '''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. | * 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 CSharp Conversions|non-trivial Java to C# conversions]]. | + | * Check out the list of [[GitSharp/Non Trivial Java To CSharp Conversions|non-trivial Java to C# conversions]]. |
- | * Please make sure you base your porting work on the same version of the [http://github.com/henon/jgit/tree/master jgit code] as all other developers to avoid inconsistencies. | + | * Please make sure you base your porting work on the same version of the [http://github.com/henon/parallelip-jgit/tree/master 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. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + |
Revision as of 18:54, 2 November 2009
Contents |
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 Freaks] 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
Note: we changed issue tracker from github to code.google.com
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.