Carlos Rovira
> Sent: Wednesday, March 27, 2013 6:47 PM
> To: dev@flex.apache.org
> Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
> Hi Alex,
>
> as I said this is a matter of taste, but we are using git with huge
> projects for months an
evert '
Thanks,
-Fred
-Message d'origine-
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 6:47 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Hi Alex,
as I said this is a matter of taste, but we are using git with
gt; this is really a matter of tastes. Each one should be happy with his
>> way
>>>>>> of proceed
>>>>>
>>>>> What should I do a git wiki with the good practices if at the end
>> everyone
>>>>> does what he wants, I gues
if at the end
> everyone
> >>> does what he wants, I guess we can try as written in the wiki for one
> month
> >>> and if it doesn't fit we can change it (but really, I think everyone
> will be
> >>> happy with it).
> >>>
>
Barragan
Sent: Wednesday, March 27, 2013 6:06 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
That's the point Alex...
Any solve can resolve as a single commit or in a change set, and this
decision, under what criterial it does?
-
;> What should I do a git wiki with the good practices if at the end everyone
>>> does what he wants, I guess we can try as written in the wiki for one month
>>> and if it doesn't fit we can change it (but really, I think everyone will be
>>> happy with it).
>>
>> If you look closely to the ASCII graph I wrote, you might have noticed there
>> are no crossed lines, it's really linear, one commit/jira at time, I really
>> maintain it is more readable and reflect more what the people really
>> develops, there's no artific
arch 27, 2013 5:36 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Another point Carlos,
this is really a matter of tastes. Each one should be happy with his way
of proceed
What should I do a git wiki with the good practices if at the
; and if it doesn't fit we can change it (but really, I think everyone will be
> happy with it).
>
> Thanks,
> -Fred
>
> -Message d'origine-
> From: Frédéric THOMAS
> Sent: Wednesday, March 27, 2013 5:22 PM
> To: dev@flex.apache.org
> Subject: Re: [2
e can change it (but really, I think everyone will be
happy with it).
Thanks,
-Fred
-Message d'origine-
From: Frédéric THOMAS
Sent: Wednesday, March 27, 2013 5:22 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Yeah, for sure
ificial forced merge.
Thanks,
-Fred
-Message d'origine-
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 4:03 PM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
IMHO this is hard to see, and even more for people outside or co
evelop [Carlos]
> * ...
>
> I hope that will be display well.
>
> -Fred
>
> *From:* Jose Barragan
> *Sent:* Wednesday, March 27, 2013 1:26 PM
> *To:* dev@flex.apache.org
> *Subject:* Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
>
&g
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Here's how it would Develop, after merging the branches of Charles and Fred, as
you can see, thereby properly appreciate the content of the two applied
Tickets.
However, Justin's commit b5da14a, is visua
hings as it is useless to
use a gun to kill a fly.
Thanks,
-Fred
-Message d'origine-
From: Carlos Rovira
Sent: Wednesday, March 27, 2013 10:24 AM
To: dev@flex.apache.org
Subject: Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Hi Frederic,
in our experience
u
>>> did for a new jira ticket and as you may don't know the final number of
>>> commits you will have at the end, once it is the time to merge, you know
>>> the number of commits you did, if you realize you've got only one, it is
>>> better to do a 'git
f a 'git merge --no-ff
> > , the reason behind that is that you can avoid the extra merge
> > commit, practically nothing change, except you will have a flat history
> > which is what we want for only one commit and it could be reverse/reset
> the
> > same if needed.
tically nothing change, except you will have a flat history
> which is what we want for only one commit and it could be reverse/reset the
> same if needed.
>
> Thanks,
> -Fred
>
> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
> vs+Bad+Git+usage<
> http
' instead of a 'git merge --no-ff
>>> , the reason behind that is that you can avoid the extra merge
>>> commit, practically nothing change, except you will have a flat history
>>> which is what we want for only one commit and it could be reverse/reset the
>&g
/FLEX/Good+**
> vs+Bad+Git+usage<https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>
> -----Message d'origine- From: carlosrov...@apache.org
> Sent: Wednesday, March 27, 2013 3:12 AM
> To: comm...@flex.apache.org
> Subject: [2/2] git commit: Me
3:12 AM
To: comm...@flex.apache.org
Subject: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Merge branch 'FLEX-33349' into develop
* FLEX-33349:
Fix TypeError #1009 happening in dataProviderRefreshed() of List.as after
refreshing the dataProvider of Combobox.
P
20 matches
Mail list logo
