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/sbt and > 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
