]> source.dussan.org Git - redmine.git/commitdiff
Delete doc/git.rdoc.
authorToshi MARUYAMA <marutosijp2@yahoo.co.jp>
Wed, 27 Apr 2011 22:40:53 +0000 (22:40 +0000)
committerToshi MARUYAMA <marutosijp2@yahoo.co.jp>
Wed, 27 Apr 2011 22:40:53 +0000 (22:40 +0000)
http://www.redmine.org/projects/redmine/wiki/Contribute?version=27 has the github mirror link.

git-svn-id: svn+ssh://rubyforge.org/var/svn/redmine/trunk@5557 e93f8b46-1217-0410-a6f0-8f06a7374b81

doc/git.rdoc [deleted file]

diff --git a/doc/git.rdoc b/doc/git.rdoc
deleted file mode 100644 (file)
index aa1b624..0000000
+++ /dev/null
@@ -1,36 +0,0 @@
-= Contributing to Redmine with git and github
-
-(This is a beta document.)
-
-The mirror repository is at http://github.com/edavis10/redmine
-
-Branches:
-
-* master - is automatically mirrored to svn trunk.
-* [0.6, 0.7, 0.8, 0.9, 1.0,...]-stable - is automatically mirrored to svn release branches. DO NOT COMMIT OR MERGE INTO THIS BRANCH
-
-== Branch naming standards
-
-Redmine has two kinds of development:
-
-* bug fixes
-* new feature development
-
-Both bug fixes and new feature development should be done in a branch named after the issue number on Redmine.org.  So if you are fixing Issue #6244 your branch should be named:
-
-* 6244
-* 6244-sort-people-by-display-name (optional description)
-* issue/6244 (optional "issue" prefix)
-* issue/6244-sort-people-by-display-name (optional prefix and description)
-
-That way when the branch is merged into the Redmine core, the correct issue can be updated.
-
-Longer term feature development might require multiple branches.  Just your best judgment and try to keep the issue id in the name.
-
-If you don't have an issue for your patch, create an issue on redmine.org and say it's a placeholder issue for your work. Better yet, add a brief overview of what you are working on to the issue and you might get some help with it.
-
-== Coding Standards
-
-Follow the coding standards on the Redmine wiki: http://www.redmine.org/wiki/redmine/Coding_Standards#Commits.  Make sure you commit logs conform to the standards, otherwise someone else will have to rewrite them for you and you might lose attribution during the conversion to svn.
-
-