ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre-John Mas <>
Subject Re: Hoped for advantages of migrating to git
Date Wed, 30 Apr 2014 23:00:19 GMT
Fair point. 

My experience has been the same. Was a little stubborn at first, but once I made the move
from Subversion I haven't looked back. One thing that I found it fixed, in my environment,
is avoiding devs using the main source control as a form of backup. 


Sent from my phone. Envoyé depuis mon téléphone. 

> On 30 Apr 2014, at 18:48, Josh Suereth <> wrote:
> 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 <>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 <>
>>> 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 <> 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 <
>>>> 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
>>>> see how long it takes to switch branches / load the repository
>> initially.
>>>> - The Peanut Gallery (Josh)
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message