Git is great for making small branches for things like bugfixes, features, refactors, etc. That plus it's way faster than Subversion. Freaky fast.
On 30 April 2014 09:01, Josh Suereth <joshua.suer...@gmail.com> wrote: > 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) > -- Matt Sicker <boa...@gmail.com>
