I wrote some paragraphs about using Git. I thought about modifying the http://camel.apache.org/contributing.html (New paragraph between "Submitting patches" and "Becoming a committer"). But because this is a bigger change I want to discuss that before.
So what do you think? Jan h2. Working with Git While several committer are working with Git, it is not the primary version control system at Apache Software Foundation. This is because the ASF has to ensure that each commit into the codebase is correct licensed. With the current VCS - Subversion - only committers with a signed CLA have write access. But there are several ways how Git users could improve Camel with their prefered tool: * git-svn * Apache Git Mirror * Pull request at Github The minor "problem" is creating the local repository connected to the official repository. Next step is modifying the codebase. The major "problem" then is getting the modifications back to the official ASF repository. Depending on the chosen way these steps differ which is short described here. h3. git-svn With Git you cannot fork another Git repository - you also could "fork" a subversion repository. {code} git svn clone https://svn.apache.org/repos/asf/camel/trunk <TargetDirectory> {code} If you have write access to the codebase you could fork from the https-adress and just "push" your changes back: {code} git svn dcommit -m "message" {code} Without that privilege you could follow the [recommended workflow|https://git-wip-us.apache.org/docs/workflow.html]: working on a feature branch, create a patch and attach it to Jira. Attaching to Jira has the benefit for the community that you are enforced to grant explicitly the license to the ASF. {code} git format-patch origin/trunk {code} h3. Apache Git Mirror Forking the Git repo from here is much smoother, because you are forking a "real" Git repo. {code} git fork git://git.apache.org/camel.git <TargetDirectory> {code} Bringing your modifications back to Apache is the [same workflow as described before|https://git-wip-us.apache.org/docs/workflow.html]. Drawback of this Apache Git repository is that it is a "mirror" with a day relay. So you are one day behind the community ... h3. Pull request at Github There is also a Git [repository at Github|https://github.com/apache/camel] which you could fork. Then you work on a new feature branch and send a pull request. For granting the license you also should create a Jira issue with a reference to that pull request. One of the committers then could bring that changesets to the ASF codebase via his/her own local repository. After closing the Jira issue you have to close the pull request because we can't do that... Same drawback here - it is one day behind ... h3. More resources Git is not a brand new technology and therefore Camel is not the only ASF project thinking about using it. So here are some more resources you mind find useful: * http://wiki.apache.org/general/GitAtApache: Some basic notes about git@asf * http://git.apache.org/: List of mgit-mirrors at ASF * https://git-wip-us.apache.org/: More Git infos from Apache -----Ursprüngliche Nachricht----- Von: Daniel Kulp [mailto:dk...@apache.org] Gesendet: Dienstag, 5. Februar 2013 15:31 An: dev@camel.apache.org; Jan Matèrne Betreff: Re: Github It is acceptable as issuing a pull request shows intent to contribute. However, we have no way to close pull requests after we pull them. In general, if we pull the request, we then have to send a note back to the original requester to have them close it. Not a huge deal, but an extra step. That said, it's not a bad thing to have the original author verify that the code was completely pulled correctly and such. Dan On Feb 5, 2013, at 8:10 AM, Jan Matèrne <j...@materne.de> wrote: > I have seen some "accepted pull requests" here on the list. > > Are pull requests "officially accepted" as patches? > > (new Jira issue with link to the pull request?) > > > > https://github.com/apache/camel > > > > > > Jan > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com