incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <>
Subject Re: What would it take to move to Git?
Date Mon, 13 Aug 2012 16:23:01 GMT

On 8/13/12 12 :13PM, "Omar Gonzalez" <> wrote:

>On Monday, August 13, 2012, Carol Frampton wrote:
>> On 8/11/12 2 :30AM, "Alex Harui" < <javascript:;>>
>> >
>> >Tomorrow I will try to commit something and if it works, we'll start a
>> >vote
>> >on Monday.
>> I assume/hope the VOTE would be at least 48 hours since I now have to
>> everything I was working on to go learn enough about Git to vote.
>> I would also like to paste from one of Bertrand's emails last week to
>> reiterate his warning message [1]:
>> Let me add one BIG WARNING as a mentor: branches might be much easier
>> to manage with Git, but if a move to Git is a way to avoid agreeing on
>> how branches are managed, that won't help IMO. I would recommend
>> sorting that problem (which is a community problem, not a technical
>> one) in svn first before considering a move.
>> As far as I can figure there has been no agreement on branching
>> Carol
>> [1]
>I wouldn't vote for Git at this point as I feels there is too much push
>back from people that don't want to learn it, because none of the
>put against it are really that convincing, it's mostly that people just
>don't want to learn it.
>The way Apache (doesn't) supports Git kind of sucks anyhow, as it
>essentially leaves sVN as the primary and uses Git as an interface
>I will be doing all my work in Git and usin git svn dcommit as soon as I
>can get it set up, whatever branching strategy gets agreed upon, anyhow.
>In regard to the branching strategy, I still believe the Git Branching
>Model is the way to go, even in SVN. Everything else that has been
>sounds like chaos and has all been presented without a very clear
>The GBM is clear, thought out, and in my experience using it works
>extremely well.

I don't disagree (or agree) that the Git branching strategy might be the
best but I think whatever the branching strategy is proposed needs to be
spelled out so everyone is on the same page on what that means for each
case we've been discussing (short-term dev, longer term dev that might not
be finished for the next release, hot fixes, etc).  We need to be very
clear on what we are all agreeing on so people don't have to know what the
Git branching strategy or any other strategy means from just a few


View raw message