I'd argue that the convenience of pull requests in ASF should be a fixable problem. If ASF is running repositories, Gerrit would be a great way to set up an elegant ASF workflow...
In any case, I applaud the effort to migrate to get and understand the concerns. My experience has been truly great moving to git. On Wed, Apr 30, 2014 at 6:33 PM, Andre-John Mas <andrejohn....@gmail.com>wrote: > Could we conceive of having a GitHub project, that serves as a point for > pull-requests and other community work and at the same time have a git repo > at Apache that syncs with this? > > > André-John > > Sent from my phone. Envoyé depuis mon téléphone. > > > On 30 Apr 2014, at 17:33, Nicolas Lalevée <nicolas.lale...@hibnet.org> > wrote: > > > > Even if I share some of your enthusiasm with git, don't forget that git > at the ASF isn't like git in github. Pull request, code review and so on is > not as integrated as in github. > > > > Nicolas > > > >> Le 30 avr. 2014 à 16:01, Josh Suereth <joshua.suer...@gmail.com> a > écrit : > >> > >> If you don't mind some recommendations from the peanut gallery (been > using > >> git for 5 years now) > >> > >> > >> On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert <anto...@gmx.de > >wrote: > >> > >>> > >>> Hello Maarten, > >>> > >>> I do not know a lot about git either. > >>> > >>> Here are the advantages I see in migrating to git : > >>> > >>> - git allows third-parties to clone an original repository and in fact > to > >>> create a fork while keeping the possibility of contributing back what > they > >>> have created if they want to, and also importantly to incorporate > inside > >>> their branches changes done elsewhere including in the reference > >>> repository. So I see git as having the same strategic importance for > the > >>> source code like the fact of uploading the ant jars to maven central > is for > >>> the use of the binaries. > >> This is pretty huge. The cost of contributions is a lot lower *and* you > can > >> perform magic on branches (git rebase) before submitting to upstream > >> projects. We (sbt + Scala) generally have a workflow of: > >> > >> 1. hack, hack, hack on our own clone/branch with a name "wip" > >> 2. When done (across the group working on it), rebase the commits and > clean > >> up the commit messages to be as useful as possible > >> 3. Submit a pull request, code review, go back to #1 as necessary > >> 4. Merge into master, delete local branch, continue work. > >> > >> Not only that, we're already using the git Ivy mirror to collaborate > >> between sbt devs and outside ivy contributors. It's a very good model > for > >> highly distributed (i.e. OSS) teams where coordination of contributions > is > >> hard. > >> > >> > >>> - for the developers of the Apache project - us - the small advantages > are > >>> to be able to commit stuff locally on our computers before pushing > when we > >>> are happy with our changes. Also one can switch branch very quickly > within > >>> the same workspace when using git, this might be an advantage. > >> I often run 3-5 branches of code for OSS projects. 1-2 of "itch > >> scratching" and 1-3 of "bug fixing". It's a great thing. > >> > >> > >>> - because of the popularity of git I imagine that the change is good > for > >>> the long run but this is speculation > >> Popularity definitely puts it above something like mercurial. It also > >> means the tooling for git has become pretty good over the past few > years. > >> JGit even provides really good Git support for programatic access. > >> > >> > >> > >>> I imagine that some corporations, individuals,or other open source > >>> organizations will take advantage of our projects moving to git to > create > >>> these forks, either because the contribution process via JIRA is too > slow, > >>> or because they want to create proprietary enhancements, or because > they > >>> are not sure that the changes that they do match the views /plans... > of our > >>> the Ant/Ivy/Ivyde/Easyant Apache project. > >> From an sbt perspective, you'd see us attempting to contribute things > back > >> far more often than we do now. If you'd like an example project that > >> contains website assets in it, feel free to checkout github.com/sbt/sbtand > >> see how long it takes to switch branches / load the repository > initially. > >> > >> - The Peanut Gallery (Josh) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
