flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [2/2] git commit: Merge branch 'FLEX-33349' into develop
Date Wed, 27 Mar 2013 17:52:38 GMT
Hi Carlos,

If you could take the time to show an example where having a 1 commit branch
helped you "gain control" that would help me and probably others understand
the tradeoffs.


On 3/27/13 10:47 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> wrote:

> Hi Alex,
> 
> as I said this is a matter of taste, but we are using git with huge
> projects for months and when we are merging and generating releases and we
> end wanting to easily see *all* branches to quickly see what we want to do,
> without taking care if a branch is 1 commit or 10, since this make you gain
> control of revert something if you need at some point in time. You end
> having more control and people not involved in a particular development can
> easily see what happened.
> 
> Right now I think is difficult to see since we are starting in GIT, but as
> GIT graph evolve we will see more complex representations and will be
> difficult to see quickly the GIT history. As I pass for that *problem*
> before, I already adopted the way to make always a branch although I have
> only one commit, but again, I recognized that it's a matter of tastes and
> it's difficult to sell the idea if you like not do it.
> 
> 
> 
> 2013/3/27 Alex Harui <aharui@adobe.com>
> 
>> I"m used to SVN's linear history. I like the fact that Git can show branch
>> history, and like the idea that I can do multiple commits before pushing
>> and
>> each of those commits is clearly shown in the history.
>> 
>> But if I don't want to show those multiple commits or I don't have multiple
>> commits, my instinct would be to just make it a linear entry.  I think
>> Carlos is saying there is some advantage to not doing that, and I want to
>> know what that advantage is.
>> 
>> 
>> On 3/27/13 10:06 AM, "Jose Barragan" <jose.barragan@codeoscopic.com>
>> wrote:
>> 
>>> 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?
>>> --
>>> Jose Barragan
>>> Chief Software Architect
>>> Codeoscopic Madrid
>>> C/. Infanta Mercedes, 92.
>>> Planta 5.  505.
>>> 28020 Madrid.
>>> Tel.: +34 912 94 80 80
>>> 
>>> On Mar 27, 2013, at 6:02 PM, Alex Harui <aharui@adobe.com> wrote:
>>> 
>>>> At minimum, if we can't decide on one particular practice, can we get a
>>>> better understanding of what problem is solved by a single commit in a
>>>> branch?  Then those who are trying to decide what to do can make a
>> better
>>>> decision.
>>>> 
>>>> 
>>>> On 3/27/13 9:36 AM, "Frédéric THOMAS" <webdoublefx@hotmail.com> wrote:
>>>> 
>>>>> 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 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).
>>>>> 
>>>>> 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, it's your point of view and happily everyone's got one
>> and
>>>>> not everyone the same, but from what I see from the current graph on
>> the
>>>>> develop branch or the one gave by Jose plus the explanations you gave,
>> I
>>>>> have the impression to see and hear "Why should I do simple when I can
>> do
>>>>> complicated".
>>>>> 
>>>>> 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 artificial 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 coming
>> some
>>>>> time later in time, but that's only my opinion... I think we should not
>>>>> stand too much on these topics and going forward since this is really
a
>>>>> matter of tastes. Each one should be happy with his way of proceed
>> while
>>>>> making things properly since both ways are right. This is much more
>> like
>>>>> trying to realize how to format code, each developer will do in its own
>>>>> way....put the bracket in the same line? in the next line?. I think we
>>>>> should be more interested in the overall GIT workflow that ensure that
>> we
>>>>> all can share our contributions and make the repo safe of problems.
>>>>> 
>>>>> 
>>>>> 
>>>>> 2013/3/27 Frédéric THOMAS <webdoublefx@hotmail.com>
>>>>> 
>>>>>>  It should have been like that even:
>>>>>> 
>>>>>> *     Merge branch ŒFLEX-33451¹ into develop [Fred]
>>>>>>  *   FLEX-33451: Fixed .gitignore                      [Fred]
>>>>>>  *   FLEX-33451: Tempora...                              [Fred]
>>>>>>  *   FLEX-33451: Fix TLF                                     [Fred]
>>>>>> *     FLEX-33349: Fix type error                          [Carlos]
>>>>>> *     removed copy of empty.bundles...            [Justin]
>>>>>> *     FLEX-28946 committed patch...                  [Cyrill]
>>>>>> *     Merge branch ŒFLEX-21066¹ into develop  [Carlos]
>>>>>>  *   FLEX-21066: implemented remove item... [Carlos]
>>>>>>  *   FLEX-21066: add removeItemError...          [Carlos]
>>>>>>  *   FLEX-21066: add removeItem to list...        [Carlos]
>>>>>> *     Merge branch ŒFLEX-33408¹ into develop   [Carlos]
>>>>>>  *     ...
>>>>>> 
>>>>>> I hope that will be display well.
>>>>>> 
>>>>>> -Fred
>>>>>> 
>>>>>> *From:* Jose Barragan <jose.barragan@codeoscopic.com>
>>>>>> *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
>>>>>> 
>>>>>> 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 visually hidden under the branch
>> of
>>>>>> Cyrill.
>>>>>> 
>>>>>> Thanks,
>>>>>>    --
>>>>>> *Jose Barragan*
>>>>>> *Chief **Software Architect*
>>>>>> Codeoscopic Madrid
>>>>>> C/. Infanta Mercedes, 92.
>>>>>> Planta 5.  505.
>>>>>> 28020 Madrid.
>>>>>> Tel.: +34 912 94 80 80
>>>>>> 
>>>>>> On Mar 27, 2013, at 11:13 AM, Frédéric THOMAS <
>> webdoublefx@hotmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> Having the rule of one commit doesn't generated an extra merge commit
>> and
>>>>>> makes the log history more readable and because you know that
>> corresponds
>>>>>> to 1 single task/jira/file, it's still easy to find it back without
>> the
>>>>>> visual pollution of the extra useless merge commit.
>>>>>> 
>>>>>> For the dictator-lieutenant model, we're not as big as linux kernel,
>> maybe
>>>>>> one day, in between I wouldn't like to introduce hierarchy in an
>> apache
>>>>>> model where it doesn't fit, anyway, look at what I said for the
>> bugfix I
>>>>>> just shared, "I'll do the merge at the end" which means I'll re-write
>>>>>> commits in order, clean up what has to be clean if any, etc.., it's
>> not
>>>>>> the
>>>>>> dictator-lieutenant model but a collaborative one which say as a
lazy
>>>>>> consensus someone will merge/ clean up at the end, as you can see
at
>> the
>>>>>> end, no needs for a dictator model to do the same things 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 working with GIT we saw that was extremely helpful
>> to
>>>>>> have visual track of each set of commits that are a single fix,
>>>>>> functionality, feature or whatever, since you can always operate
and
>> have
>>>>>> much control as branches grow and ramifies. In the particular case
you
>>>>>> point (single commit - flat history) it's a matter of tastes but
>> making it
>>>>>> flat for this particular case makes you lost visibility as GIT
>> workflow
>>>>>> evolve over time. Right now we could make it flat (at this point
of
>>>>>> simplicity), but I recommend not to do it since in few months we
>> should
>>>>>> expect more complex GIT graphs and this kind of loops will help to
see
>>>>>> others what historically happen.
>>>>>> 
>>>>>> Apache Flex is so huge and modular and over time we should organize
>> in a
>>>>>> way that make us possible to plan huge releases with lots of modules,
>>>>>> changes and consistence between pieces. We are right now at the very
>>>>>> beginning trying to get the basic management and functionality but
as
>>>>>> people will understand the full potential of the tool and the kind
of
>>>>>> thinks we can now do, things will complicate. As we discussed in
other
>>>>>> thread some weeks ago, I suspect that we will end in an
>>>>>> "dictator-lieutenant-apache" model (as we talked with Beltran the
>> apache
>>>>>> part is that decisions must be consolidated in this list to adopt
such
>>>>>> model), since it's what I see in other big open source projects where
>> sub
>>>>>> teams are organized in repositories and they commit in such
>> repositories
>>>>>> while the "lieutenant" assemble the final "module" (this happen in
the
>>>>>> same
>>>>>> way all the way to root until reach the "dictator"). As we said,
if
>> we end
>>>>>> in this model, the apache way will be less restricted in repo
>> permissions
>>>>>> and more conducted by the list where people will assign the tasks
to a
>>>>>> single person.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2013/3/27 Frédéric THOMAS <webdoublefx@hotmail.com>
>>>>>> 
>>>>>> Hi Carlos,
>>>>>> 
>>>>>> This merge you did make me think I didn't talk about this case on
the
>> wiki
>>>>>> [1], so I updated it, in short, while it is good to start a branch
as
>> you
>>>>>> 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 rebase <my_branch>' instead of a 'git merge
>> --no-ff
>>>>>> <my_branch>, 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.
>>>>>> 
>>>>>> Thanks,
>>>>>> -Fred
>>>>>> 
>>>>>> [1] https://cwiki.apache.org/**confluence/display/FLEX/Good+**
>>>>>> vs+Bad+Git+usage<
>>>>>> 
>> https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage>
>>>>>> 
>>>>>> -----Message d'origine----- From: carlosrovira@apache.org
>>>>>> Sent: Wednesday, March 27, 2013 3:12 AM
>>>>>> To: commits@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.
>>>>>> 
>>>>>> 
>>>>>> Project:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/repo<
>> http://git-wip-us.ap
>>>>>> ac
>>>>>> he.org/repos/asf/flex-sdk/repo>
>>>>>> Commit: http://git-wip-us.apache.org/**repos/asf/flex-sdk/commit/**
>>>>>> 39fdf7fa <
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/39fdf7fa>
>>>>>> Tree:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/tree/**39fdf7fa<
>> http://gi
>>>>>> t-
>>>>>> wip-us.apache.org/repos/asf/flex-sdk/tree/39fdf7fa>
>>>>>> Diff:
>>>>>> http://git-wip-us.apache.org/**repos/asf/flex-sdk/diff/**39fdf7fa<
>> http://gi
>>>>>> t-
>>>>>> wip-us.apache.org/repos/asf/flex-sdk/diff/39fdf7fa>
>>>>>> 
>>>>>> Branch: refs/heads/develop
>>>>>> Commit: 39fdf7fa81329fa60eb95efc374375**a901c34d3d
>>>>>> Parents: 6282657 5ca083e
>>>>>> Author: Carlos Rovira <carlos.rovira@gmail.com>
>>>>>> Authored: Wed Mar 27 03:12:08 2013 +0100
>>>>>> Committer: Carlos Rovira <carlos.rovira@gmail.com>
>>>>>> Committed: Wed Mar 27 03:12:08 2013 +0100
>>>>>> 
>>>>>> 
>> ------------------------------**------------------------------**----------
>>>>>> .../projects/spark/src/spark/**components/List.as    |   23
>>>>>> +++++++++++----
>>>>>> 1 files changed, 17 insertions(+), 6 deletions(-)
>>>>>> 
>> ------------------------------**------------------------------**----------
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Carlos Rovira
>>>>>> Director de Tecnología
>>>>>> M: +34 607 22 60 05
>>>>>> F:  +34 912 94 80 80
>>>>>> http://www.codeoscopic.com
>>>>>> http://www.directwriter.es
>>>>>> http://www.avant2.es
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>> 
>>> 
>> 
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>> 
>> 
> 
> 
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Mime
View raw message